In message <20050731012146.GA27236@bi-paterson.demon.co.uk> Ross Paterson
On Sat, Jul 30, 2005 at 01:04:46PM -0700, Isaac Jones wrote:
Also, I noticed the "FIXME" that mentions the -x flag is only supported on some platforms; what effect will this have on platforms that don't support it? Will they be broken during build? What about platforms where we know the ghci libs don't work, like MacOS; will this patch cause building to break?
In fact this should allow it to work on MacOS and Solaris (as long as we get the -x thing right). I don't think the previous method worked on MacOS or Solaris.
fptools/ghc/utils/ghc-pkg/Main.hs has 3 #ifdef'd versions, all with -x, though.
Actually the fptools versions all use $(LD_X) which expands to -x or nothing depending on an autoconf test. The autoconf test just checks if ld accepts -x so it doesn't tell us which platforms that works on.
The patch adds a couple extra configure options, --enable-library-for-ghci / --disable-library-for-ghci. I'm sorta thinking of just having one option "--disable-interpreter-libs" or something to make this seem more generic, though at the moment, it still only makes sense for a combo compiler / interpreter build (that is, --ghc). I'll be happy to add this to the manual once we settle on a flag. Do we ever really need to disable it anyway?
I don't see the point of any option in this case.
Not all libs build/work with GHCi because of technical problems (eg Gtk2Hs on Win32). But maybe that indicates it should be something set by the package author in the .cabal file rather than by the user as a ./setup configure flag. But actually the main reason to add these flags was to support the way I know some people build RPMs, that is leaving the GHCi .o files out of the rpm file. But if we're not supporting that, then the flags can go too. Duncan