Boost logo

Boost :

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2005-06-18 11:09:55

On Tue, 2005-06-14 at 12:34 -0400, Stefan Seefeld wrote:
> David Abrahams wrote:
> > 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.
> I agree that duplicating the data manually would be a maintenance nightmare.
> On the other hand, I don't think users of boost libraries should be required
> to know about bjam either.
> What I imagine is some 'database' (m4 file for autoconf, pkg-config file,
> whatever) that is *generated* by bjam as part of the build process.
> Unix developers are quite used to the idea: tools such as pkg-config
> work exactly like that. Appropriate files are generated during configuration /
> installation, and can be further tuned during the packaging, if necessary.
> Again, I'm thinking of platforms such as Fedora or Debian, which both have
> their own package management tools. If I want to develop software that
> is to use boost rpm or deb packages, I'd much appreciate some standardization
> of how to query the boost package(s) about required flags. If this isn't
> done as part of the boost project itself, packagers will do it, but probably
> not in a consistent way.

I agree with you. Linking against Boost is difficult; I've had to fight
this problem in the past as I'm the package maintainer of Boost under
NetBSD (in fact, under pkgsrc, a portable packaging system). The
untypical names in the library names make this task very complex (and
very error prone).

It seemed to me that building with --layout=system was the solution,
because then I'd simply rename the libraries to
and the linking became trivial (-lboost_whatever) from any project that
needed Boost: no need to know which toolset was used, which features
were enabled (e.g., multithread), etc. Unfortunately, I just learned
that this is incorrect, mostly because the libraries were built under
NetBSD without soname support (due to a problem in the .jam files, not
my fault ;).

So... I've been using the following m4 code in my configure scripts to
look for Boost:

---- snip ----

           [String suffix that identifies Boost libraries (empty by

         [AC_CHECK_HEADERS($2, ,
                           AC_MSG_FAILURE([cannot find Boost.$1

          m4_if($#, 3, [
                suffixes=${BOOST_SUFFIX:-"none -gcc -mipspro -mt
                for BOOST_SUFFIX in ${suffixes}
                    test ${BOOST_SUFFIX} = none && BOOST_SUFFIX=

                    AC_MSG_CHECKING(for -l${libname})
                    LIBS="-l${libname} ${LIBS}"
                    AC_LINK_IFELSE([int main(void) { return 0; }],

                    test ${found} = yes && break
                if test ${found} = no; then
                    AC_MSG_FAILURE([cannot find the Boost $1 library])

---- snip ----

And as an example, to detect some required libraries:

---- snip ----

BOOST_CHECK([Format], [boost/format.hpp])
BOOST_CHECK([Smart Pointers], [boost/shared_ptr.hpp])
BOOST_CHECK([Utility], [boost/noncopyable.hpp])

            [boost/filesystem/convenience.hpp \
             boost/filesystem/fstream.hpp \
             boost/filesystem/operations.hpp \

---- snip ----

Note that this is very far from simple, and many times it requires help
from the user to find them (i.e., setting BOOST_SUFFIX) :-(

Having .pc files could be indeed nice; just do something like
'pkg-config --libs boost_filesystem' and forget! I'm sure these could
be "easily" generated on the fly by Boost.Build to minimize maintenance

Also nice could be to have a --layout=system feature that used names
that were completely system-agnostic (currently, I'm getting '-mt'
embedded into them, although it shouldn't be there, IMHO).


Julio M. Merino Vidal <jmmv84_at_[hidden]>
The NetBSD Project -

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