[boost] pkg-config for Boost

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-02-09 13:23:56

Dear All,

I maintain a couple of open-source apps that use Boost, and my users 
seem to encounter Boost-related compilation problems more often than 
I'd like.

One common problem is that the names of the libraries are different on 
different systems.  On my Debian system I have, for example, 
/usr/lib/libboost_thread.so which is a symlink to 
libboost_thread-gcc-mt-1_33_1.so.  My makefile used the shorter name, 
but then I discovered that some other distributions don't have this 
symlink - and I believe also that someone who has compiled Boost from 
source will not have it (is that true?).  OK, so I can use the longer 
name, but should I hard-code the compiler, thread model, and version 
numbers?  I've never tried to compile my code with a different 
compiler; it's never going to run on Windows but someone might try the 
Sun or Intel compilers one day, and I don't want to stop that; do I 
just put $(CC) in there?  As for the version, well I'm hopeful that it 
will still work when 1.34 is released so again I'm not enthusiastic 
about hard-coding 1.33.1.

Another problem is that some people will have installed Boost in a 
different directory like /usr/local or /opt or ~.

I'd like to have all this stuff "just work" without users needing to 
edit Makefiles or similar.

There are, of course, several tools that help solve this sort of 
thing.  GNU autotools (automake, autoconf etc.) are the best-known in 
the Linux world and many people seem to like them, but I find their 
mountains of automagically generated shell scripts rather scary, and 
impossible to debug.  I'm aware of Boost's own bjam but feel that each 
library having its own build system is a bit like each library having 
its own (incompatible) string type.

The approach that I prefer is to write a simple Makefile and to use 
config scripts to find library configurations.  Many libraries supply 
config scripts that can be invoked by make to determine include and 
library directories and other settings.  For example, libpng has libpng-config:

$ libpng-config --cflags
-I/usr/include/libpng12
$ libpng-config --libs
-lpng12

The makefile can then do
CFLAGS += `libpng-config --cflags`
and so on.

An alternative to each library crafting its own script is the 
pkg-config program.  (man pkg-config).  I believe that this is quite 
widely deployed, but I'm not certain about that.  In this case, each 
library only needs to install a ".pc" file somewhere that the 
pkg-config program can find it.  You can then invoke "pkg-config 
--cflags libname" etc.  The .pc file is quite simple, e.g. here is the 
one for libexif:

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libexif
Description: Library for easy access to EXIF data
Requires:
Version: 0.6.13
Libs: -L${libdir} -lexif -lm
Cflags: -I${includedir}/libexif

As you can see it needs to be customised (by adjusting the first line) 
when the library is installed, though most is boilerplate.

So, I think it would be great if Boost could ship a set of .pc files, 
one per library.  Google tells me that this hasn't been done before.  
Any thoughts?  Can you see any issues that would make this difficult?

If you feel that this would be a valuable addition to the project, I 
would be happy to contribute template .pc files to get started with.  
However, since I have never built Boost from source and know nothing 
about the build system, I hope that someone else would volunteer to 
integrate the files into the build system.

I look forward to your comments.

(Please CC: me in any replies as I am subscribed to the digest.)

Regards,

Phil.