From: Andreas Pokorny (andreas.pokorny_at_[hidden])
Date: 2004-12-15 13:23:15
On Wed, Dec 15, 2004 at 05:13:44PM +0000, Jonathan Wakely <cow_at_[hidden]> wrote:
> The only problem with this approach I can see is that Boost consists of
> *lots* of libraries, not a single libboost.so - so IIUC there would have
> to be pkgconfig files for each lib, and possibly for each combination of
> toolset, debug/release, ST/MT, for each lib!
Exactly, thats why pkg-config might not be the right tool. I would
suggest that the features of pkg-config get extended by boost needs.
( extend => reimplement as boost application )
Thus one has to add the ability to specify flags that affect the output.
> This might be something that packagers should add themselves if they
> ship a single, pre-packaged, system-wide Boost. (By which I mean,
> RedHat could add pkgconfig to their boost RPM, because they only ship
> a single libboost_regex.so, not libboost_regex-gcc-mt-1_32.so and
> other toolset/build/thread combos).
In my opinion that feature must be provided by boost. Imagine suse
packaging boost with boost_python-1.32.pc and boost_threads-1.32.pc ...
and redhat doing the same but the pkg-config files get named like
libboostpython-1.32.pc ... The users of boost would suddenly have the
same problem, just on a different level.
> Another, related option, is a boost-config script that allows you to
> specify which libs you want, and which versions, e.g.
> boost-config thread regex signals --libs
> might output:
> -L/usr/lib/ -lboost_regex -lboost_thread -lboost_signals
> boost-config regex --libs --toolset=gcc --build=mt
> might output:
> -L/usr/lib/ -lboost_regex-gcc-mt-1_32
> A number of projects I know provide a file like this, which is almost as
> easy to use in autoconf/automake as pkgconfig (there are standard macros
> for using such a file in place of pkgconfig).
Yes, that makes using boost much simpler. One could also output proper
flags for include directories, so packagers could install several
versions of boost on one system.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk