atom feed3 messages in org.haskell.cabal-develpkg-config support
FromSent OnAttachments
Duncan CouttsMay 22, 2006 6:48 pm 
Simon MarlowMay 24, 2006 6:21 am 
Duncan CouttsMay 24, 2006 6:36 am 
Subject:pkg-config support
From:Duncan Coutts (
Date:May 22, 2006 6:48:02 pm

So here's a feature I was thinking of implementing but I'd just like to check that people think it is an appropriate thing to implement.

pkg-config is a system that many C libraries now use for managing the C compiler flags needed to build programs that use those libraries.

If you check on any recent Linux system you will find some version of pkg-config and if you run pkg-config --list-all you should see a sizable list of libraries.

Haskell bindings libraries that use such C libs need to call pkg-config as part of their build system to work out what compiler flags to use (and just to check that a suitable version of the C lib is installed).

Of course this is just one instance of a more general issue of where the flags needed to build a package are not constant and have to be discovered at configure time.

Anyway, so the idea is that one could add easy support for pkg-config to Cabal. It'd use pkg-config to check that the appropriate version of the lib is installed and discover the cc-options and ld-options necessary to compile and link to that C lib.

So my question is: would it be sensible to add this feature to Cabal, probably in the form of yet another field in the .cabal file or should we look at something more general?

It'd be very convenient to be able to just say:

pkg-config-depends: dbus-1 >= 0.60

On the other hand I can see that we should worry about an ever increasing list of fields in the .cabal file.

As a comparison, with autoconf they have a (large) number of macros for common stuff which can then be extended by other packages that are installed. So if you install pkg-config then it installs some additional macros which do the pkg-config version checks and find the CFLAGS & LIBS etc.

So of course it would be possible to implement this pkg-config stuff using hooks on a per-package basis. Though of course one would want to factor out that common code and put it in a library. Cabal would be the obvious library to put it in of course. So (to play devils advocate) if it'd probably go in Cabal either way, why would we want to make it harder to use by insisting that pkg-config features are accessed via Setup.lhs rather than a simple one line in the .cabal file.

I don't know which is the best way. It comes back to the dilemma over how much goes into the declarative .cabal file and how much goes into opaque Haskell code in Setup.lhs.