[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Haskell dependencies for custom cabal builds

From: John Soo
Subject: Re: Haskell dependencies for custom cabal builds
Date: Tue, 12 Feb 2019 16:02:44 -0800

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?


> 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:
> <>
> Note that it was "fixed" briefly by these commits:
> <>
> Unfortunately it was later reverted due to breaking some edge(?) cases,
> and a Nix-specific workaround that I don't really understand was merged:
> <>
> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]