Duncan Coutts:
On Fri, 2005-07-29 at 01:39 +0100, Duncan Coutts wrote:
Hi Manuel,
Attached is a darcs patch to c2hs to add support to the lexer and parser for asm statements and annotations. It also adds support for the string literal concatenation feature of C.
Sorry I messed up the patch slightly and missed a bit out. Attached is the correct patch.
Note that this is a replacement patch, it's not cumulative.
Thanks! Your patch is in the public repo now.
BTW, we've still got another patch that's we probably need before we can use the mainline c2hs again. However I don't understand it! I'll have to get Axel to look into that one. :-) It's something in the GenBind module. As I recall it was something to do with foreign pointers.
How big is the change?
I was experimenting with using your mainline c2hs to build Gtk2Hs. It generates lots of little .h files and uses them in the foriegn import declerations. The behaviour of our c2hs fork (at least when using the precompiled headers feature) was not to mention any .h file in the foreign import decleration. That way we only have to mention the .h files that we pass to c2hs in the ghc package files and more importantly we do not need to distribute all the .h files. Indeed these .h files are always trivial, they just #include the main .h file we passed to c2hs in the frist place. So is there a way to avoid generating the .h files if they are trivial?
Not including any .h in foreign imports is not a portable way of using the FFI. The only feasible "optimisation" for c2hs seems to be that if it generates a "foo.h" with only #include "lib.h" then it could drop "foo.h" and put "lib.h" into the foreign import declaration. That'd be a reasonable, generally useful feature, which I'd be happy to include. I'd prefer not applying this "optimisation" by default, though, but only when requested via a command line option. That is as some people may rely on the .h generated by c2hs in their packages. Is that a reasonable compromise?
I note that with c2hs now using cabal that it requires at least ghc 6.2. In that case would patches that depend on library updates that come with ghc 6.2 be ok? I'm thinking of the finite map libraries since the ghc ones are rather faster. I recall there being a measurable speedup when I switched them in the Gtk2Hs fork of c2hs.
I am happy to rely on anything that is in the hierarchical libraries of GHC 6.2 *and* of nhc98 and Hugs. I'd like to keep the code base portable. AFAIK, Data.Map is portable. Thanks again for the patch, Manuel