...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
Boost.Build is a system for large project software construction built on Boost.Jam, a descendant of "Perforce Jam", an open-source make replacement[1]. Key features are:
Here are some of the design criteria that led to these features.
Boost.Build responds to several global variable settings. The easiest
way to get going is usually to use environment variables, though you can
also set them on the command-line, using
-sVARIABLE_NAME=value. In addition to the
toolset configuration
variables, you can use the TOOLS variable to indicate which
toolset(s) to build with, and the BUILD variable to describe how
you want things built. In many cases it should be sufficient to invoke
bjam
with no variable settings.
Some example Boost.Jam invocations:
Command Line(s) | Effects |
---|---|
bjam -sTOOLS=gcc my_target |
default (debug) BUILD of my_targetwith GCC |
bjam "-sTOOLS=msvc gcc" |
default-build all with msvc and gcc |
set TOOLS=msvc bjam |
Set an NT environment variable to always build with MSVC default-build all. |
bjam "-sBUILD=release <debug-symbols>on" |
release build with debug symbols of all using default TOOLS |
bjam "-sBUILD=debug release" |
debug and release build all. |
set TOOLS=msvc |
Set an NT environment variable to always build with MSVC default-build all, adding a compiler command line switch |
set TOOLS=msvc gcc |
Set an NT environment variable to always build with MSVC and
GCC default-build all, adding a MSVC-specific compiler command line switch |
bjam "-sBUILD=<define>BOOST_POSIX" |
build all, with the macro BOOST_POSIX defined for all compilers |
The "-s" options in the command lines above are passing variable settings to the build system. There are actually three ways to do that:
This approach can be OK for quick-and-dirty tests, but environment variable settings tend to be unstable and non-uniform across users and machines, so it's best not to rely on the environment much.> BUILD="debug release" # assuming Unix > export BUILD > bjam ...
subproject foo/bar/baz ; # path to here from project root # A static library called 'baz' lib baz : baz1.cpp baz2.cpp # C++ sources parser/src/baz4.ll # Lex->C++ sources parser/src/baz5.yy # Yacc->C++ sources : <include>$(BOOST_PARENT_DIRECTORY) # Put boost in #include path ; # An executable called 'test' exe test : <lib>baz # use the 'baz' library baz_test.cpp # C++ source : <include>$(BOOST_ROOT) ;
That's it! The build system takes care of the rest. If the you want to be able to build all subprojects from the project root directory, you can add a Jamfile at the root:
project-root ; # declare this to be the project root directory # Read subproject Jamfiles subinclude foo/bar/baz foo/bar/... ; subinclude a/b/c ... ; # more subincludes
To use the build system, the following must be located in your project's root directory, or in a directory specified in the BOOST_BUILD_PATH variable. It is usually convenient to specify the BOOST_BUILD_PATH in your project's Jamrules file. The Boost Jamrules file shows an example.
Filename(s) | Meaning |
---|---|
toolset-tools.jam | Feature-to-command-line mapping for toolset. |
features.jam | Abstract toolset feature descriptions. |
boost-base.jam | Boost build system-specific rule definitions. |
unit-tests.jam | Unit tests and assertions for boost Jam code. |
A project is a source directory tree containing at least one Jamfile. The root directory of the project is known as the project root. The root directory of a project may contain a Jamrules file, which contains project-specific Jam code. If the Jamrules file is not present when Jam is invoked, a warning will be issued.
Subdirectories containing Jamfiles are called subproject directories. Each such Jamfile describes a subproject.
The build system installation directory is a directory containing Jam files describing compilers and build variants. The installation directory can be specified in a file called boost-build.jam in the project root directory. This file should contain a line boost-build $path-to-installation-dir. If no such file is available the environment variable BOOST_BUILD_PATH will be used. This lists a set of directories to search for the files comprising the build system. If the installation directory is not specified, it is the same as the project root, and BOOST_BUILD_PATH is set to include that directory.
Each Jamfile describes one or more main targets.
Each main target is an abstract description of one or more built targets which are expressions of the corresponding main target under particular compilers and build variants. Intermediate files such as .o/.obj files generated by compiling .cpp files as a consequence of building a main target are also referred to as built targets. The term build directory tree refers to the location of built target files.
A feature is a normalized (toolset-independent) description of an individual build parameter, such as whether inlining is enabled. Each feature usually corresponds to a command-line option of one or more build tools. Features come in four varieties:
A feature-value pair is known as a build property, or simply property. The prefixes simple, free, path, and dependency apply to properties in an analogous way to features.
A build variant, or simply variant is a named set of build properties describing how targets should be built. Typically you'll want at least two separate variants: one for debugging, and one for your release code.
Built targets for distinct build variants and toolsets are generated in separate parts of the build directory tree, known as the variant directories. For example, a (sub)project with main targets foo and bar, compiled with both GCC and KAI for debug and release variants might generate the following structure (target directories in bold).
bin +-foo <--- foo's build root | +-gcc | | +-debug | | `-release | `-kai | +-debug | `-release `-bar <--- bar's build root +-gcc | +-debug | `-release `-kai +-debug `-release
The properties constituting a variant may differ according to toolset, so debug may mean a slightly different set of properties for two different compilers.
When a target is built with simple properties that don't exactly match those specified in a build variant, the non-matching features are called subvariant features and the target is located in a subvariant directory beneath the directory of the base variant. This can occur for two reasons:
Because the default value of runtime-link is dynamic, when the debug variant is requested, the runtime-link-dynamic subvariant of foo is built.bin +-foo <--- foo's build root | +-msvc | | +-debug . . . `-runtime-link-dynamic . . .
bin +-foo <--- foo's build root | +-msvc | | +-debug . . . +-runtime-link-dynamic . . . `-runtime-link-static . . .
When a subvariant includes multiple subvariant features, targets are built into a subvariant directory whose path is determined by concatenating the properties sorted in order of their feature names. For example, the borland compiler, which uses different libraries depending on whether the target is a console or GUI program, might create the following structure for a DLL:
bin +-foo <--- foo's build root | +-msvc | | +-debug | | | +-runtime-link-dynamic | | | | +-user-interface-console | | | | `-user-interface-gui . . . `-runtime-link-static . . . +-user-interface-console . . . `user-interface-gui
Any configuration of properties for which a target is built, whether base variant or subvariant, is known as a build configuration, or simply a build.
When a main target depends on the product of a second main target (as when an executable depends on and links to a static library), each build configuration of the dependent target is depends on the corresponding build of the dependency. Because only simple features participate in build identity, the dependent and dependency targets may have completely different free features. This puts the onus on the user for ensuring link-compatibility when certain free properties are used. For example, when assert() is used in header files, the preprocessor symbol NDEBUG can impact link-compatibility of separate compilation units. This danger can be minimized by encapsulating such feature differences inside of build variants.
This section describes how to start a build from the command-line and how to write project and subproject Jamfiles. It also describes the other files written in the Jam language: build-tool specification files, feature descriptions files.
This section describes in detail how the build system can be invoked.
The Jam command line ends with an optional list of target names; if no target names are supplied, the built-in pseudotarget all is built. In a large project, naming targets can be dicey because of collisions. Jam uses a mechanism called grist to distinguish targets that would otherwise have the same name. Fortunately, you won't often have to supply grist at the command-line. When you declare a main target, a Jam pseudotarget of the same name is created which depends on all of the subvariants requested for your invocation of the build system. For example, if your subproject declares:
and you invoke Jam with -sBUILD="debug release" my_target, you will build both the debug and release versions of my_target.exe my_target : my_source1.cpp my_source2.c ;
These simple, ungristed names are called user targets, and are only available for the subproject where Jam is invoked. That way, builds from the top level (which may include many Jamfiles through the subinclude rule) and builds of library dependencies (which may live in other subprojects), don't collide. If it is necessary to refer more explicitly to a particular target from the command-line, you will have to add ``grist''. Please see this section for a more complete description of how to name particular targets in a build.
This is a partial list of global variables that can be set on the command-line. Of course you are free to write your own Jam rules which interpret other variables from the command-line. This list just details some of the variables used by the build system itself. Note also that if you don't like the default values you can override them in your project's Jamrules file.
Variable | Default | Example | Notes |
---|---|---|---|
TOOLS | Platform-dependent | "-sTOOLS=gcc msvc" | build with gcc and msvc |
-sTOOLS=gcc | build with gcc | ||
BUILD | debug | -sBUILD=release | build the release variant |
"-sBUILD=debug release" | build both debug and release variants | ||
"-sBUILD=<optimization>speed" | build a subvariant of the default variant (debug) with optimization for speed. | ||
"-sBUILD=debug release <runtime-link>static/dynamic" | build subvariants of the debug and release variants that link to the runtime both statically and dynamically. | ||
ALL_LOCATE_TARGET | empty | -sALL_LOCATE_TARGET=~/build | Generate all build results in the build subdirectory of the user's home directory (UNIX). |
A subproject's Jamfile begins with an invocation of the subproject rule that specifies the subproject's location relative to the top of the project tree:
subproject path-from-top ;
The subproject rule tells the build system where to place built targets from the subproject in case ALL_LOCATE_TARGET is used to specify the build directory tree. If there is a Jamfile in the project root directory, you should use the project-root rule instead:
project-root ;
A main target is described using the following syntax:
target-type name : sources [ : requirements [ : default-BUILD ] ] ;
The location specifies the location of a Jamfile in which a dependency target calleddependency-target -> type-tag location target-name type-tag -> "<template>" | "<lib>" | "<dll>" | "<exe>" location -> ( @project-id/ )? relative-path relative-path -> ( path-element/ ) *
target-name
can be
found, declared with the given type-tag. Other type-tags
are possible; for example the python.jam
module defines Python extensions with the "<pyd>"
tag. If @project-id
is specified, the
relative-path is interpreted with respect to the root directory
of the specified project. Otherwise, it
is interpreted with respect to the directory of the current Jamfile.
The dependency's type-tag is also used to decide how to link to it when needed. <lib> targets are linked statically and <dll> targets are linked dynamically. On Unix platforms dynamic linking will use (the appropriate platform equivalent of) LD_LIBRARY_PATH and the "-l" linker flag to avoid creating executables which expect to find dynamic libraries in particular locations in the filesystem.
NOTE: It is important to match the type-tag dependency with the type of the dependency target. Trying to specify a type-tag of <lib> when the target is defined as a <dll> will cause an error.
<compiler> and <variant>, if supplied, can be used to restrict the applicability of the requirement. Either one may be replaced by <*>, which is the same as omitting it.[[<compiler>]<variant>]<feature>value
The system checks that simple feature requirements are not violated by explicit subvariant build requests, and will issue a warning otherwise. Free features specified as requirements are simply added to each corresponding build configuration.
When multiple values are specified, it causes all the implied configurations to be built by default. It is also possible to prevent any default builds from occurring on this target by using[[<compiler>]<variant>]<feature>value1[/value2...]
<suppress>true
. This suppresses any local targets,
either implicit or explicit, from building. But, this does not prevent
implied targets as required by a dependency by another target to this
one from being built. This is useful, for example, for defining a set
of libraries generically and having them built only when another target
like an exe is built. Such use might look like:
With that the basic library will only be built when the test executable is built, and only the variations required by the executable will be built.lib basic : basic.cpp : : <suppress>true ;
exe test : test.cpp <lib>basic ;
NOTE: for simple features in both requirements and default-BUILD, more-specific qualification overrides less-specific.
Template targets provide a way to handle commonalities between projects targets. They have the same form as main targets but do not initiate build requests. A target that lists a template as a dependency inherits all the settings from the template, i.e. the templates sources, requirements and default build settings will be added to the targets settings. Paths mentioned in a template definition are always relative to the subdirectory of the Jamfile containing the templates definition, regardless of the subdirectory of the dependent main target. Typically a project will have at least one template target that handles defines, include paths and additional compiler flags common to all targets in the project.
Stage targets are a special kind of target that don't build a single file but to a collection of files. The goal is to create a directory which is composed of the various files that other targets generate, or individual files. When built a stage target creates a directory with the same name as the target, and copies the dependent files to it. The form of the target is the same as that of main targets with some differences...
<tag><feature|variant>value
This artificially complex example shows how two executables called "foo" and "fop" might be described in a Jamfile. All common settings are factored out in the templates "base" and "executable". Foo is composed of the sources ./foo.cpp and ./src/bar.cpp (specified relative to the directory in which the Jamfile resides). Fop only has one sourcefile ./fop.cpp. Both executables link against the built target which results from building the target baz as described in ../bazlib/Jamfile.
template base : ## Requirements ## : <include>../bazlib/include <define>BUILDING_FOO=1 <release><define>FOO_RELEASE <msvc><*><define>FOO_MSVC <msvc><release><define>FOO_MSVC_RELEASE <gcc><*><optimization>off <gcc><release><optimization>space <threading>multi <sysinclude>/usr/local/foolib/include ## default-BUILD ## : debug release <debug><runtime-link>static/dynamic ; template executable : <template>base <lib>../bazlib/baz ; exe foo : <template>executable foo.cpp src/bar.cpp ; exe fop : <template>executable fop.cpp ;
The requirements section:
The default-BUILD section:
project
rule to declare a project id and
location for the external project. Then add the appropriate external
dependency target specification to your program's
list of sources. For example, if you are developing a program which uses
the Boost.Threads library, you might write
in your Jamrules file, and placeproject boost : /home/dave/boost-cvs ;
in your target's list of sources.<dll>@boost/libs/thread/build/boost_thread
Target requirements support the use of auxiliary rules to allow for more complex decisions about the requirements. If specified, by using the name of a rule in the requirements, the rule is called with the signature: ( toolset variant : subvariant-path properties * ) and should return the modified set of properties. There are a number of built-in rules for some common tasks that Boost uses, and you can use:
Rule Effects std::locale-support Ensures that locale support is available for the target. For example some toolsets, like CodeWarrior, locale support is only available on specific platforms using a static runtime. std::facet-support Ensures that facet support is available for the target. common-variant-tag Adds a constructed prefix tag to the target to conform to the Boost common naming conventions for libraries. The tag is constructed as:
[-<toolset-tag>][-<thread-tag>][-<runtime-tag>][-<version-tag>]
- <toolset-tag> maps to an abbreviated name of the toolset and when possible, and applicable, the version of the toolset.
- <thread-tag> "mt" when multi-threading is enabled.
- <runtime-tag> adds these single letter tags:
"s" when static linking to runtime
"g" when linking to debug runtime
"y" when building debug-python variants
"d" when building debug variants
"p" when building with stlport libraries
"n" when building with stlport and using native iostreams- <version-tag> adds "major_minor" from a <version> property. Defaults to using $(BOOST_VERSION) if no version property is present.
Installable files and targets are described with:
install name type : sources... : [options]... ;
Install descriptions define files and targets that can be installed by use of a stage target.
Install descriptions are meant to be used by stage targets to collect the various sources of many install descriptions into one or more destination directories. For this there are two rules that help in getting the sources specified:
Features are described by stating the feature type (simple features are specified with "feature"), followed by the feature name. An optional second argument can be used to list the permissible values of the feature. Examples can be found in features.jam.
Variants are described with the following syntax:
The variant rule specifies the list of properties comprising a variant. Properties may be optionally qualified with a toolset name, which specifies that the property applies only to that toolset. One or more parent variants may be specified to inherit the properties from those parent(s). For inherited properties precedence is given on a left to right order, making the immediate properties override those in the parent(s). This can be used to great effect for describing global properties that are shared amongst various variants, and therefore targets. For example:variant name [ : parent-name] : [<toolset-name>]<feature>value... ;
More examples can be found in features.jam.variant my-globals : <rtti>off ; variant my-debug : my-globals debug ; variant my-release : my-globals release ;
Toolset descriptions are located in the project's root directory, or a directory specified by BOOST_BUILD_INSTALLATION, which may be set in a Jamfile or the project's Jamrules file. Each file is called toolset-name-tools.jam, where toolset-name is the name of the toolset. The toolset description file has two main jobs:
Note that Link-action may require special care: on platforms where the global variable gEXPORT_SUFFIX(DLL) is defined (e.g. Windows), the first argument may have two elements when linking a shared library. The first is the shared library target, and the second is the import library target, with suffix given by $(gEXPORT_SUFFIX(DLL)). It will always have a third argument which is either ``EXE'' or ``DLL''. This can be used to dispatch to different actions for linking DLLs and EXEs if necessary, but usually it will be easier to take advantage of the special <target-type> feature, which will have the same value using the flags rule described below.rule C++-action { msvc-C++-action $(<) : $(>) ; } actions msvc-C++-action { cl -nologo -GX -c -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I$(HDRS) -I$(STDHDRS) -Fo$(<) -Tp$(>) }
The parameters are:flags toolset variable condition [: value...]
Semantics only affect targets built with the specified toolset, and depend on the target's build configuration:
The description of the flags rule above is actually more complicated than it sounds. For example, the following line might be used to specify how optimization can be turned off for MSVC:
It says that the string /Od should be added to the global CFLAGS variable whenever a build configuration includes the property <optimization>off.flags msvc CFLAGS <optimization>off : /Od ;
Similarly, in the following example,
we add /MD to the CFLAGS variable when both of the specified conditions are satisfied. We could grab all of the values of the free feature <include> in the HDRS variable as follows:flags msvc CFLAGS <runtime-build>release/<runtime-link>dynamic : /MD ;
flags msvc HDRS <include> ;
The use of these variables should be apparent from the declaration of actions msvc-C++-action in the previous section.
In addition to user targets, which correspond directly to the names the user writes in her subproject Jamfile, several additional targets are generated, regardless of the directory from which Jam was invoked:
This section describes some of the global variables used by the build system. Please note that some parts of the system (particularly those in allyourbase.jam) are heavily based on the Jambase file supplied with Jam, and as such do not follow the conventions described below.
Global variables used in the build system fall into three categories:
ECHO $(gFUBAR($(x),$(y))) ;
Please note that the build system commonly takes advantage of Jam's Dynamic Scoping feature (see the local command in the "Flow of Control" section below the link target) to temporarily "change" a global variable by declaring a local of the same name.
Many of the variables that are used to configure how Boost.Build works internally are listed here with brief descriptions.
The requirements are driven by several basic assumptions:
This build system was designed to satisfy the following requirements:
[2] Note: right now, a dependency feature of a main target makes all resulting built targets dependent, including intermediate targets. That means that if an executable is dependent on an external library, and that library changes, all the sources comprising the executable will be recompiled as well. This behavior should probably be fixed.
Revised 8 September, 2003
Copyright © Dave Abrahams 2001.
Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at www.boost.org/LICENSE_1_0.txt)