Cabal and Hsc2hs Build Phase Options
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? 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. Cheers, Matt
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
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
participants (2)
-
Duncan Coutts -
Matthew William Cox