on when to build ghci libs in cabal
Henning Günther and Duncan Coutts / the Gentoo team have sent me a patch to move creation of ghci libs to the build phase rather than the register phase. It makes more sense there and should be somewhat better for debian and gentoo. Though Duncan points out that maybe some ppl want to build the ghci libs during register because it could save room in a binary distribution (like debian and rpm). Any opinions here? 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? 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? peace, isaac
On Sat, Jul 30, 2005 at 01:04:46PM -0700, Isaac Jones wrote:
Henning Günther and Duncan Coutts / the Gentoo team have sent me a patch to move creation of ghci libs to the build phase rather than the register phase. It makes more sense there and should be somewhat better for debian and gentoo.
Though Duncan points out that maybe some ppl want to build the ghci libs during register because it could save room in a binary distribution (like debian and rpm). Any opinions here?
I'd favour doing all the building in the build phase. And part of the purpose of binary distributions is to trade space for time.
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?
fptools/ghc/utils/ghc-pkg/Main.hs has 3 #ifdef'd versions, all with -x, though.
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.
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
On 7/30/05, Isaac Jones
Henning Günther and Duncan Coutts / the Gentoo team have sent me a patch to move creation of ghci libs to the build phase rather than the register phase. It makes more sense there and should be somewhat better for debian and gentoo.
I think it is better too. But, the current code assumes that "ld" is in the system path. On windows, without Cygwin or MinGW, this is usually not the case. People will add only, e.g. c:\ghc\ghc-6.4.1\bin to the path. But, GHC's copy of ld.exe is in "c:\ghc\ghc-6.4.1\gcc-lib." Also, if MinGW or Cygwin is being used, then the "ld" in the path might be different than the one GHC normally uses. I recommend invoking "ld" just like ghc-pkg does: #if defined(darwin_HOST_OS) r <- rawSystem "ld" ["-r","-x","-o",ghci_lib_file,"-all_load",batch_lib_file] #elif defined(mingw32_HOST_OS) execDir <- getExecDir "/bin/ghc-pkg.exe" r <- rawSystem (maybe "" (++"/gcc-lib/") execDir++"ld") ["-r","-x","-o",ghci_lib_file,"--whole-archive",batch_lib_file] #else r <- rawSystem "ld" ["-r","-x","-o",ghci_lib_file,"--whole-archive",batch_lib_file] #endif I agree that "--enable-library-for-ghci" and "--disable-library-for-ghci" are unnecessary. - Brian
Though Duncan points out that maybe some ppl want to build the ghci libs during register because it could save room in a binary distribution (like debian and rpm). Any opinions here?
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?
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?
peace,
isaac _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Brian Smith
the current code assumes that "ld" is in the system path. On windows, without Cygwin or MinGW, this is usually not the case. People will add only, e.g. c:\ghc\ghc-6.4.1\bin to the path. But, GHC's copy of ld.exe is in "c:\ghc\ghc-6.4.1\gcc-lib." Also, if MinGW or Cygwin is being used, then the "ld" in the path might be different than the one GHC normally uses. I recommend invoking "ld" just like ghc-pkg does:
#if defined(darwin_HOST_OS) r <- rawSystem "ld" ["-r","-x","-o",ghci_lib_file,"-all_load",batch_lib_file] #elif defined(mingw32_HOST_OS) execDir <- getExecDir "/bin/ghc-pkg.exe" r <- rawSystem (maybe "" (++"/gcc-lib/") execDir++"ld") ["-r","-x","-o",ghci_lib_file,"--whole-archive",batch_lib_file] #else r <- rawSystem "ld" ["-r","-x","-o",ghci_lib_file,"--whole-archive",batch_lib_file] #endif
Brian sent me a patch for this which I've pushed out. Can I get other Windows testers, please? peace, isaac
participants (4)
-
Brian Smith -
Duncan Coutts -
Isaac Jones -
Ross Paterson