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 8, 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.

tag

The tag feature is used to customize the name of the generated files. The value should have the form:

@rulename

where rulename should be a name of a rule with the following signature:

rule tag ( name : type ? : property-set )

The rule will be called for each target with the default name computed by Boost.Build, the type of the target, and property set. The rule can either return a string that must be used as the name of the target, or empty string, in which case the default name will be used.

Most typical use of the tag feature is to encode build properties, or library version in library target names. You should take care to return non-empty string from the tag rule only for types you care about — otherwise, you might end up modifying names of object files, generated header file and other targets for which changing names does not make sense.

debug-symbols

Allowed values: on, off.

The debug-symbols feature specifies if produced object files, executables and libraries should include debug information. Typically, the value of this feature is implicitly set by the variant feature, but it can be explicitly specified by the user. The most common usage is to build release variant with debugging information.


PrevUpHomeNext