[C2hs] RE: darcs patch: added cppOptions and c2hsOptions
vivian.mcphail at paradise.net.nz
Fri Apr 20 00:31:16 EDT 2007
I added cppOptions because in the Cabal.cabal file there was a comment to
add cppOptions and so I did it.
With respect to c2hsOptions, the problem is that c2hs passes options to the
CPP nonstandardly (with --cppopts=), so even if I have an -I* option in my
ccOptions that gets passed to c2hs, this works for c2hs, but doesn't get
passed to the cpp that c2hs uses.
I've sent a message to the c2hs/cabal mailing list with a dummy package that
recreates all the problems I had on mingw/WinXP. The reason the c files are
outside the Cabal hierarchy is that they are supposed to mimic libs/headers
that are already on the system and would (normally) be found with an
I think it would be a great idea to change the name of the .h file that c2hs
generates. It would make naming Haskell sources/modules more consistent
with their targets.
> -----Original Message-----
> From: Duncan Coutts [mailto:duncan.coutts at worc.ox.ac.uk]
> Sent: Wednesday, 18 April 2007 3:31 p.m.
> To: Vivian McPhail
> Cc: cabal-devel at haskell.org
> Subject: Re: darcs patch: added cppOptions and c2hsOptions
> On Wed, 2007-04-04 at 03:33 +1200, Vivian McPhail wrote:
> > Wed Apr 4 03:32:49 New Zealand Standard Time 2007 Vivian McPhail
> > <omconsult at gmail.com>
> > * added cppOptions and c2hsOptions
> Hia Vivian,
> Can you explain to me again exactly why we need these extra options?
> As I see it, cpp options can just be included in the cc options, is
> there any need to separate them?
> Cabal currently looks for -D* -U* and -I* flags in the cc options and
> passes them to c2hs. Are there any other ones that we are missing
> It's quite convenient for users not to have to separate the cc flags
> into cpp ones, since many other tools intermingle them (off the top of
> my head I can think of pkg-config).
> As for the c2hs options, again I'm not clear as to why this is
> necessary. c2hs doesn't support that many interesting flags:
> -C CPPOPTS --cppopts=CPPOPTS pass CPPOPTS to the C preprocessor
> -c CPP --cpp=CPP use executable CPP to
> invoke C preprocessor
> -d TYPE --dump=TYPE dump internal information
> (for debugging)
> -h, -? --help brief help (the present message)
> -i INCLUDE --include=INCLUDE include paths for .chi files
> -k --keep keep pre-processed C header
> -l --copy-library copy `C2HS' library module in
> -o FILE --output=FILE output result to FILE
> (should end in .hs)
> -p PLATFORM --platform=PLATFORM platform to use for cross
> -t PATH --output-dir=PATH place generated files in PATH
> -v --version show version information
> I think all of these are either not useful or can be selected
> As for the optional .h file that can be passed on the command line,
> the better way to do that is to put the #include inside the .chs file.
> The alternative is to extend c2hs to accept many .h files on the
> command line and we can pass all the files in the 'includes:' field to
> c2hs. I'm considering extending c2hs to allow this. I'm also planning
> to change c2hs so that the .h file it generates will not clash with
> anything else, for foo.chs it'll generate foo.chs.h and possibly
> foo.chs.c too.
> Is there anything I've missed?
More information about the C2hs