pkg-config support

Duncan Coutts duncan.coutts at
Mon May 22 17:19:56 EDT 2006

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

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.


More information about the cabal-devel mailing list