[boost] [boost.build] RFE: pkg-config

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2005-06-14 09:08:48

Hi there,

many moons ago we had a discussion about how to tell users about
build flags necessary to build software that uses boost libraries.
Was there any consensus about how to do that ?

Let me briefly resume the problem I'm facing. I'm writing software
that uses boost libraries (boost.python, boost.wave, etc.). I'v been
working with current snapshots, which provide libraries such as
libboost_python-gcc-mt-1_33.so.
However, I can't hardcode that name into my build scripts, as at
some point after boost 1.33 gets officially released, I may take
a boost package provided by the OS distributor I'm using. Chances
are high that the boost libraries will be named differently then,
i.e. instead of libboost_python-gcc-mt-1_33.so I will get
'libboost_python.so'. There are many more issues, which we already
discussed in detail (library dependencies, required compilation flags,
etc., etc.).

The real problem is that this situation requires some cooperation between
boost developers and boost packagers, or else the burden of figuring
out all these details falls on the user.

Thus I think it would be great for boost to provide some kind of
table that users can inspect to figure out all the metainfo about
the libraries they need. This table would be created in a transparent
way that encourages packagers to recreate it to reflect the way they
package boost.

As I'm working mostly with unix, a natural candidate for such a table
is 'pkg-config' (an option that was suggested before), but I can see
some developers not wanting to use any specific tool.

An alternative would be to develop a boost-specific tool that then
becomes part of every boost package, and which users can query
such as 'which additional libraries do I need to link with when
using library 'XYZ' ?' etc.

However, that tool should be neutral, i.e. while it should be able
to provide all the data required to build software with boost,
it must not assume any particular build system (make, bjam, scons,
whatever).

Is there any work done in this direction ?

Thanks,
                Stefan