Hi John, John Soo <js...@asu.edu> writes:
> Hi there, > > I did a little digging this morning and it seems like runhaskell is > probably deprecated in favor of runghc. Do we expect anyone to be > using hugs or jhc? Runghc also supports ghc flags. I still need to do > some more research here but the Haskell configure phase deliberately > unsets GHC_PACKAGE_PATH. I assume it does this because runhaskell > supports many Haskell compilers. If custom cabal builds are rare, I > would suspect that non-ghc builds are even rarer. Would it be possible > to replace runhaskell with runghc? Or parameterize the command? I don’t see how this would help. >From the build system code, Cabal errors if GHC_PACKAGE_PATH is set during 'configure', so unset and restore it. The issue that git-annex has is that it wants to use some packages before calling into Cabal. If “GHC_PACKAGE_PATH” is set properly, it will find the packages, proceed normally until calling Cabal, and then error because Cabal doesn’t like “GHC_PACKAGE_PATH”. Cabal wants to setup the package search path from the command line arguments instead. On the other hand, if “GHC_PACKAGE_PATH” is not set, Cabal would theoretically work, but we never get there! The custom “Setup.hs” code errors out with missing packages before ever calling Cabal. I don’t think that switching from “runhaskell” to “runghc” changes that. -- Tim