Hi, On Wed, Dec 15, 2004 at 05:13:44PM +0000, Jonathan Wakely <cow@compsoc.man.ac.uk> wrote: [snip]
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
and 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. Regards Andreas Pokorny