Detrimental c2hs / "other-modules" interaction

[Duncan Coutts]

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