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

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

Projects

None yet

2 participants

@bos
Haskell member

(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

@bos
Haskell member

(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.

@bos
Haskell member

(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).

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@bos
Haskell member

(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.

@tibbe
Haskell member

Nothing activity in 6 years, so closing.

@tibbe tibbe closed this Jan 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment