Boost logo

Boost Users :

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2004-06-26 09:31:47

On Thu, Jun 24, 2004 at 10:32:20PM -0500, Vincent N. Virgilio wrote:
> Petri Latvala wrote:
> >>is somewhere documented how to add automake/autoconf stuff for boost to a
> >>project? I have a set of small testcases and the need
> >>boost_unit_test_framework-gcc library to compile. At the moment I add the
> >>lib directly to linker options with
> >>
> >>project_test_LDADD = -lboost_unit_test_framework-gcc
> >>
> >>But this is not platform independent, because someone might have not gcc
> >>installed.

Worse; in boost 1.31, there are now *four* pieces of build variant
information encoded in the library name: toolset, threading, runtime,
and version (

> AC_SEARCH_LIBS(...) might do it handily. You'd list the variant library
> names in the second argument. This would select the first library found;
> limited, but not bad for a first cut.

Yeah, but with four variant pieces, the combinatorics really work
against this approach. I don't know how you'd guess the boost version
to use, for example.

> Either approach could be made more flexible by adding appropriate
> '--with-<~boost-option>' flags to to help construct the
> target boost library name(s).

This is probably your only real option: introduce a
"--with-boost-variant" option so that the installer can specify the
variant to use, i.e. the "toolset-threading-runtime-boostversion"

For the Debian boost packages, by the way, we introduced an extra
symlink for each library that DOES NOT HAVE the variant information
included. We can do this because the canonical debian packages
produce only a single variant for each library. Thus you can simply
link using "-lboost_unit_test_framework" on Debian.

If other packagers adopt this approach, it becomes feasible for an
autoconf macro to fall back to the "un-varianted" library name.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at