darcs patch: added cppOptions and c2hsOptions

[Vivian McPhail]

Hi Duncan,

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

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.

Cheers,

Vivian 

> -----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 
> there?
> 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 
> compilation
>   -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 
> automatically.
> 
> 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?
> 
> Duncan
>