On Fri, 2007-05-04 at 00:47 -0400, Michael Stone wrote:
Dear Cabal Developers,
First, thanks for the excellent work so far.
Second, I thought I'd report a frustrating experience I had on my first attempt to package a library.
Thanks.
I'm currently extracting a Cairo binding from Gtk2hs because I want to use Cairo on a server that doesn't have X or GTK readily available.
I'm a maintainer of Gtk2Hs, c2hs and Cabal and I've slowly been working towards the same goal -- of improving c2hs and Cabal sufficiently to package all the Gtk2Hs components separately with Cabal.
As I went about adapting Gtk2hs' binding, I ran into the following issue:
1) Cabal does not clean up after c2hs - in particular, it does not delete the temporary .chi and .chs.h files that c2hs produces for each file it processes.
I fixed this one a couple days ago in fact :-) If you use the latest darcs version of both c2hs and Cabal, cabal now tells c2hs to put all its generated files under ./dist/build which means we don't clutter the source dirs with generated files and deleting the dist/build dir cleans them all up.
2) Cabal does not do dependence analysis. Consequently, the "other-modules" field of my cairo.cabal is order-sensitive.
Yeah. This is very annoying. Lennart Kolmodin made a patch to do dep analysis just for the .chs files. We've not applied it yet, partly because we were looking for a more general solution and when I tested it briefly it didn't quite work. But this can probably be made to work with a little hacking. If you want to hack on it, the patch is here: http://haskell.org/~duncan/cabal/c2hs.dpatch
Together, these mean that after I manually delete those temporary files, my build fails mysteriously because the dependencies are not being resolved in an order that c2hs can work with. This in turn makes it non-trivial to make reliable builds.
Please let me know if you'd like any further information.
To be practical, I think the easiest way to get just cairo building on a server without the Gtk+ headers is to hack the current Gtk2Hs build system. You'd want to modify the configure tests so that it doesn't bother to look for gtk+, and #ifdef out the gtk modules section in Makefile.am, like we do conditionally for the other optional modules. The other reason to take this approach is that currently the cairo source code uses a feature of c2hs that is only present in the gtk2hs fork of c2hs, so it'd need more work to use the mainline c2hs. OTOH, It's only a minor change as I recall. We're aiming to switch to the mainline c2hs some time too. BTW, if you're interested in seriously using the cairo bindings, we are looking for some help in updating them to provide the current cairo-1.4 API (rather than the current cairo-1.0 API) and to get the PDF, PS and SVG backends working. At the moment the only non-X11 backend we've got is the image/PNG backend. Duncan