Re: Haskell dependencies for custom cabal builds

[Marius Bakke]

Hello!

Timothy Sample <address@hidden> writes:

> Hi John,
>
> John Soo <address@hidden> 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