Re: Haskell dependencies for custom cabal builds

[John Soo]

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 <address@hidden> wrote:
> 
> 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?