Skip to content
This repository

Cabal shouldn't try to build GHCI libs on platforms without GHCI #31

Closed
bos opened this Issue May 23, 2012 · 6 comments

2 participants

Bryan O'Sullivan Johan Tibell
Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported from Trac #24, reported by @jgoerzen on 2005-11-28)

Cabal should not attempt to do anything relating to GHCI on archs that don't support it. It shouldn't try to build ghci libs, and it shouldn't pass --auto-ghci-libs to ghc-pkg.

More information here:

https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1364839&group_id=8032

Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported comment by @syntaxpolice on 2005-11-28)

clarification: newer cabal versions don't use --auto-ghci-libs and only try to build these libs during build time, not during compile time.

Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported comment by @syntaxpolice on 2005-11-28)

Here's what simon says about discovering whether we are on a platform with ghci:

  • copy the info from mk/config.mk.in in a GHC source tree. Problem: you need to keep it up to date.
  • try running ghci and see if it works.
  • try running 'ghc -e "return ()"' and see if it works (easier than previous).
  • look for presence of HSbase.o, by asking ghc-pkg where it should be
The 'ghc -e' method is the easiest, though it'll add a delay to the
configure step (probably takes longer itself than a complete configure
taskes right now).
Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported comment by @dcoutts on 2005-12-10)

ghc-6.8 has a flag that tells us various features about the ghc installation. I think that the ghci support is one of these things. So we could support this feature in ghc-6.8 and later.

If we do this, should we drop the existing --disable-library-for-ghci flag? We could keep it if we tried the ghc -e "return ()" suggestion.

Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported comment by @dcoutts on 2007-12-30)

This is pretty easy bug but it does not seem to bother anybody enough to fix it or even comment on it. Punting.

Bryan O'Sullivan
Owner
bos commented May 23, 2012

(Imported comment by @dcoutts on 2007-09-12)

Implementing this just for ghc 6.8 and later should be easy since we can parse the output of ghc --info to find the:

 ,("Have interpreter","YES")
read the output of ghc --info at type :: [(String, String)] and lookup the key "Have interpreter" and check the corresponding value against "YES" / "NO".

That should be used to set the default of whether ghci libs are built or not. Perhaps if the user explicitly asks for them and they cannot be supported there should be a warning.

Johan Tibell
Owner

Nothing activity in 6 years, so closing.

Johan Tibell tibbe closed this January 27, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.