Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. — Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of boost. Click here for the latest Boost documentation.
PrevUpHomeNext

Builtin features

variant

A feature that combines several low-level features, making it easy to request common build configurations.

Allowed values:debug, release, profile

The value debug expands to

            <optimization>off <debug-symbols>on <inlining>off <runtime-debugging>on

The value release expands to

            <optimization>speed <debug-symbols>off <inlining>full <runtime-debugging>off

The value profile expands to the same as release, plus:

            <profiling>on <debug-symbols>on

Rationale: Runtime debugging is on in debug builds to suit the expectations of people used to various IDEs. It's assumed other folks don't have any specific expectation in this point.

link

A feature that controls how libraries are built.

Allowed values:shared, static

source
The <source>X feature has the same effect on building a target as putting X in the list of sources. The feature is sometimes more convenient: you can put <source>X in the requirements for a project and X will be included as a source in all of the project's main targets.
library
This feature is equivalent to the <source> feature, and exists for backward compatibility reasons.
dependency
Introduces a dependency on the target named by the value of this feature (so it will be brought up-to-date whenever the target being declared is), and adds its usage requirements to the build properties of the target being declared. The dependency is not used in any other way. The primary use case is when you want the usage requirements (such as #include paths) of some library to be applied, but don't want to link to it.
use
Introduces a dependency on the target named by the value of this feature (so it will be brought up-to-date whenever the target being declared is), and adds its usage requirements to the build properties of the target being declared. The dependency is not used in any other way. The primary use case is when you want the usage requirements (such as #include paths) of some library to be applied, but don't want to link to it.
dll-path
Specify an additional directory where the system should look for shared libraries when the executable or shared library is run. This feature only affects Unix compilers. Plase see the section called “Why are the dll-path and hardcode-dll-paths properties useful? ” in Chapter 27, Frequently Asked Questions for details.
hardcode-dll-paths

Controls automatic generation of dll-path properties.

Allowed values:true, false. This property is specific to Unix systems. If an executable is built with <hardcode-dll-paths>true, the generated binary will contain the list of all the paths to the used shared libraries. As the result, the executable can be run without changing system paths to shared libraries or installing the libraries to system paths. This is very convenient during development. Plase see the FAQ entry for details. Note that on Mac OSX, the paths are unconditionally hardcoded by the linker, and it's not possible to disable that behaviour.

cflags, cxxflags, linkflags
The value of those features is passed without modification to the corresponding tools. For cflags that's both C and C++ compilers, for cxxflags that's C++ compiler and for linkflags that's linker. The features are handy when you're trying to do something special that cannot be achieved by higher-level feature in Boost.Build.
PrevUpHomeNext