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@worc.ox.ac.uk] Sent: Wednesday, 18 April 2007 3:31 p.m. To: Vivian McPhail Cc: cabal-devel@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 * 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