Boost logo

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/ which is a symlink to 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
$ libpng-config --libs

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:


Name: libexif
Description: Library for easy access to EXIF data
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.)



Boost list run by bdawes at, gregod at, cpdaniel at, john at