Cabal and Hsc2hs Build Phase Options

Duncan Coutts duncan.coutts at
Wed Nov 25 05:16:40 EST 2009

On Fri, 2009-11-20 at 09:44 -0500, Matthew William Cox wrote:
> 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.

Wow, that's fairly horrible. I wonder what the MPI people were thinking.
You can't have two dependencies that use this trick since they would
fight over which cc to use. Does it let you tell it which gcc to wrap or
does it try and pick the gcc itself?

> 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.

Right, so you'll need a custom Setup.hs. It will collect the info from
your ./configure script. It will need to update the ProgramConfiguration
environment that Cabal uses. The ProgramConfiguration tells Cabal where
various named programs live and if they need any extra flags (this is
the information store that the --with-prog= and --prog-options= flags

You'll want to set the gcc to be used. That will propagate automatically
to the hsc2hs call, though not to ghc (though arguably it should).
You'll need to modify the program configuration to add in the
appropriate flags to the ghc calls.

> 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.

I'm not quite sure how that should work. The initial
ProgramConfiguration you get will contain the info from the user command
line. Can you tell the MPI thing which gcc it should wrap? If so then
you can respect the user arguments, otherwise I don't really see how you
can and also make it work.

> 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.

We've not quite decided if cabal blah --with-gcc= should set just the
gcc that cabal calls directly, or if cabal should also instruct all
programs that call gcc to use that same one. What makes me most nervous
is that ghc has a fairly intimate relationship with gcc and especially
when it comes to gcc flags, not all gcc flags are compatible with ghc.

> 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.

Would it be enough to have a central setting for which gcc to use, as
mentioned above?

> > BTW, as a short-term workaround you can always use the wrapper script
> > trick:
> I take it there's no way of doing this statically?

Not in the .cabal file. You can do what you like in the Setup.hs though.


More information about the Libraries mailing list