Boost C++ Libraries

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

User can define his own build variants using the variant rule from the common module.

Notee: Runtime debugging is on in debug builds to suit the expectations of people used to various IDEs.

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. It's useful when you want to add the same source to all targets in the project (you can put <source> in requirements) or to conditionally include a source (using conditional requirements, see the section called “Conditions and alternatives”) See also the <library> feature.
library
This feature is almost equivalent to the <source> feature, except that it takes effect only for linking. When you want to link all targets in a Jamfile to certain library, the <library> feature is preferred over <source>X -- the latter will add the library to all targets, even those that have nothing to do with libraries.
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). The dependency is not used in any other way. For example, in application with plugins, the plugins are not used when linking the application, application might have dependency on its plugins, even though , and adds its usage requirements to the build properties of the target being declared. 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 7, 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 the C and C++ compilers, for cxxflags that's the C++ compiler and for linkflags that's the linker. The features are handy when you're trying to do something special that cannot be achieved by higher-level feature in Boost.Build.
warnings
The <warnings> feature controls the warning level of compilers. It has the following values:
  • off - disables all warnings.

  • on - enables default warning level for the tool.

  • all - enables all warnings.

Default value is all.
warnings-as-errors
The <warnings-as-errors> makes it possible to treat warnings as errors and abort compilation on a warning. The value on enables this behaviour. The default value is off.
build

Allowed values: no

The build feature is used to conditionally disable build of a target. If <build>no is in properties when building a target, build of that target is skipped. Combined with conditional requirements this allows to skip building some target in configurations where the build is known to fail.


PrevUpHomeNext