Cabal and Hsc2hs Build Phase Options

Matthew William Cox matt at mattcox.ca
Fri Nov 20 09:47:58 EST 2009


On Fri, Nov 20, 2009 at 10:00:10AM +0000, Duncan Coutts wrote:
> The builder is in a position to know if special flags are needed. Also,
> since the builder controls the build environment they could use special
> flags anyway by changing the $PATH and using wrapper scripts, so there's
> no point in not letting the builder do what they want.

The author is also in a position to know that the same flags need to be
used in two different build phases. In this case, I'm using
autoconfUserHooks to find out how to use the system's MPI library. A
builder should direct the autoconf script to the correct library (if there
are multiple) using an environment variable. In either case, autoconf
hands me a compiler wrapper which needs to be used to compile and link all C
code (and the FFI using code). There's no other portable way to use MPI,
like pkgconfig or whathaveyou to suss out the magic CFLAGS and LDFLAGS
needed.

Anyways, from my perspective as an author that wants to provide the
simplist building experience for someone else, I'd rather be able to
tell them in the docs to run
  runhaskell Setup.hs configure && runhaskell Setup.hs build
rather than to 1) runhaskell Setup.hs configure, 2) read the generated
buildinfo script to determine the compiler and linker passed to ghc, 3)
call runhaskell Setup.hs build --hsc2hs-options="-cc=$COMPILER
--ld=$COMPILER" where $COMPILER is the exact compiler wrapper used by
Ghc, and failing to do this may result in failure or having a
schizophrenic build compiled against one library and linked against
another.

The user arguments at the command line should always override the ones
in a configuration file of course. That gets you the best of both
worlds.

tl;dr: you can have your cake and eat it too if the user's command line
arguments always override the equivalent configuration file directive.

> Now I take it that you really want to use your mpicc just for hsc2hs and
> not for all cases where cabal (or programs that cabal calls) call gcc
> right? I ask because we've got another open feature request ticket that
> asks that cabal --with-gcc=blah should pass that gcc on to ghc, hsc2hs,
> etc etc.

I need it for all phases of the build (GHC, hsc2hs, etc.) Right now,
it's override GHC using ghc-options: -pgmc ... -pgml ... but it would be
even better if there was one central way. Again, a --with-linker would
be nice to add, and especially, a configuration file directive to set it
statically based on an autoconf check with the option to be overridden
by a user's command line arguments.

> BTW, as a short-term workaround you can always use the wrapper script
> trick: --with-hsc2hs=hsc2hs.sh

I take it there's no way of doing this statically?

Thanks,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/libraries/attachments/20091120/77a8c497/attachment.bin


More information about the Libraries mailing list