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