![]() |
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
<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
<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
#include
paths) of some
library to be applied, but don't want to link to it.
use
#include
paths) of some
library to be applied, but don't want to link to it.
dll-path
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
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
<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.
all
.
warnings-as-errors
<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.