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

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-14 10:56:02

Stefan Seefeld <seefeld_at_[hidden]> writes:

> 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 ?

Best way: write a little Boost.Build project that uses the bits you
need, and do a bjam -n -a to see the command-lines.

> 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.

The right thing to do is generate a (BBv2) Jamfile that creates
targets for the prebuilt libraries and correctly specifies their
usage-requirements.

> 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.

The problem with adding another tool is that information can all be
generated by the build system for dependent projects.  Trying to
replicate that capability externally and keep the two in synch would
be a nightmare.  That's why this should be done with the build tool.
On the other hand, I'm not opposed to using a front-end atop
Boost.Build for this purpose.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com