Re: Haskell dependencies for custom cabal builds

[Timothy Sample <samplet@ngyro.com>]

Hi John,

John Soo <jsoo1@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.

I don’t think that switching from “runhaskell” to “runghc” changes that.


-- Tim