Boost logo

Boost :

Subject: [boost] Interface for configuring third-party dependencies
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-10-07 12:20:48


it seems that increasing number of upcoming libraries want to depend on third-
party dependencies (Locale and GIL.IO being examples) and it would be nice to
agree beforehand on an interface that is acceptable to everybody. This email
attempts to suggest such interface.

= Configuring location of dependencies =

In general, for each external dependencies Boost.Build should try to check if
it's available without configuration -- that is, in locations normally searched
by the compiler/linker. If that fails, user has two way to help the search

First, it will be possible to specify environment variables (either in OS
environment, or using Boost.Build -sVAR=VALUE command-line option).
For example, given a name of external dependency of 'zlib', the used
variables are:
        - ZLIB_ROOT

The first two specify where the headers ahd libraries are located. The
third specifies how the library file itself is named (and has sensible
defaults most of the times). ZLIB_ROOT is a shortcut to set both
include path and library path to $root/include and $roo/lib respectively.

This approach is fairly easy to use for one-off builds of Boost by users.

Second, it will possible to specify external dependencies in user-config.jam,
or any other configuration file. This approach is slightly more complicated,
as one has to edit a config file, but retains configuration and permits
to specify multiple configuration for an external dependency -- which
is not possible using environment variables. Roughly, the syntax will

        using zlib
            : condition <target-os>windows
            : include-path whatever
            : library-path something-else

The 'condition' parameter specifies when this declaration will be picked up.
Other parameters mirror the environment variables above.

= Controlling use of external dependencies =

Sometimes, it might be desirable to disable use of external dependency even
when it's available. To than end, for each external dependency a new feature
should be provided, for example:


When a value of "off" is specified, zlib won't be used by any boost component.
Also, for every specific library that uses an external dependency, a more
specific feature will be defined, for example:


to control use of that dependency in specific library.

Does anybody have comments on this?


Vladimir Prus

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