Thanks Marius, I’m feeling quite out of my depth here so thanks for the background. It seems like maintaining a fork effectively might be a lot more work. Is there really no other good way to accomplish a custom build?
John > On Feb 12, 2019, at 11:44 AM, Marius Bakke <mba...@fastmail.com> wrote: > > 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?
