Thanks Tim! Good to know! Thank you. Looking again at the call to runhaskell in the configure phase, then. It does accept --package-db as an argument. Is it feasible to parse GHC_PACKAGE_PATH into the correct package paths instead of using the environment variable?
Thanks! John > On Feb 12, 2019, at 11:21 AM, Timothy Sample <samp...@ngyro.com> wrote: > > 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
