Cabal and Hsc2hs Build Phase Options

[Duncan Coutts]

On Fri, 2009-11-20 at 02:19 -0500, Matthew William Cox wrote:
> Hello,
> 
> Firstly, is there any way to specify (statically) options to be passed
> to Hsc2hs to be used during the build phase? Ideally, extending the
> --$PROGNAME-options command line argument to a cabal directive would be
> ideal, so that hsc2hs-options: would be a valid directory for use in
> .buildinfo/.cabal files. Is there a way to specificy the compiler and
> linker to be used in the invocation of hsc2hs?

No, and that is by design.

There is a balance between things we let package authors decide and
things we let package builders decide. This is to match the situation in
the open source world where the two are different people. I realise the
division can be a bit confusing for in-house projects where the two
roles are taken by the same individual.

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.

> Secondly, there is a problem with how command line arguments are
> passed to hsc2hs. Running build with the command line argument:
>   --hsc2hs-options="--cc=mpicc --ld=mpicc" -v
> yields the following call to hsc2hs:
> 
> > Creating dist/build/dllg/dllg-tmp/System (and its parents)
> > /usr/bin/hsc2hs --cc=mpicc -ld=mpicc --cc=/usr/bin/gcc --ld=/usr/bin/gcc --cflag=-D__G...
> 
> Two compilers and two linkers are passed to Hsc2hs, but the later
> arguments (the default compilers) take precedence, as can be seen if the
> /bin/false is passed instead of mpicc.

Right. So I can certainly see that there's a use case for putting the
extra flags at the end, to override. I'm not entirely sure whether we
also have cases where they really need to be at the beginning. If so
we'd need two ways of setting program flags.

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 suggest you file a ticket with this feature request. If you want it
sorted out quickly however you'll have to do a little testing work. I
suggest starting with this patch (against Cabal HEAD) and seeing if that
sorts out the problem, and if it creates any other obvious problems.

hunk ./Distribution/Simple/Program/Run.hs 67
-programInvocation prog extraArgs =
+programInvocation prog args =
hunk ./Distribution/Simple/Program/Run.hs 70
-    progInvokeArgs = programArgs prog ++ extraArgs
+    progInvokeArgs = args ++ programArgs prog


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

Duncan