Re: Haskell dependencies for custom cabal builds

[John Soo]

Thanks Tim!

Good to know! Thank you. Looking again at the call to runhaskell in the 
configure phase, then.  It does accept --package-db as an argument. Is it 
feasible to parse GHC_PACKAGE_PATH into the correct package paths instead of 
using the environment variable?

Thanks!

John

> On Feb 12, 2019, at 11:21 AM, Timothy Sample <address@hidden> wrote:
> 
> 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.
> 
> I don’t think that switching from “runhaskell” to “runghc” changes that.
> 
> 
> -- Tim