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:[EMAIL PROTECTED] > Sent: Wednesday, 18 April 2007 3:31 p.m. > To: Vivian McPhail > Cc: [email protected] > 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 > > <[EMAIL PROTECTED]> > > * 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 > _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
