Hello! Timothy Sample <samp...@ngyro.com> writes:
> 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. FWIW here is the upstream issue: <https://github.com/haskell/cabal/issues/3728> Note that it was "fixed" briefly by these commits: <https://github.com/haskell/cabal/pull/3753> Unfortunately it was later reverted due to breaking some edge(?) cases, and a Nix-specific workaround that I don't really understand was merged: <https://github.com/haskell/cabal/pull/4193> I wonder if we should try picking the original Cabal fix from ttuegel, maybe as a separate package if it really is a breaking change. Thoughts?
signature.asc
Description: PGP signature
