|
Home | Libraries | People | FAQ | More |
Table of Contents
bjam's first job upon startup is to load the Jam code which implements the build system. To do this, it searches for a file called "boost-build.jam", first in the invocation directory, then in its parent and so forth up to the filesystem root, and finally in the directories specified by the environment variable BOOST_BUILD_PATH. When found, the file is interpreted, and should specify the build system location by calling the boost-build rule:
rule boost-build ( location ? )
If location is a relative path, it is treated as relative to the directory of boost-build.jam. The directory specified by location and directories in BOOST_BUILD_PATH are then searched for a file called bootstrap.jam which is interpreted and is expected to bootstrap the build system. This arrangement allows the build system to work without any command-line or environment variable settings. For example, if the build system files were located in a directory "build-system/" at your project root, you might place a boost-build.jam at the project root containing:
boost-build build-system ;
In this case, running bjam anywhere in the project tree will automatically find the build system.
The default "bootstrap.jam", after loading some standard definitions, loads two files, which can be provided/customised by user: "site-config.jam" and "user-config.jam".
Locations where those files a search are summarized below:
Table 23.1. Search paths for configuration files
| site-config.jam | user-config.jam | |
|---|---|---|
| Linux |
/etc $HOME $BOOST_BUILD_PATH |
$HOME $BOOST_BUILD_PATH |
| Windows |
$SystemRoot $HOME $BOOST_BUILD_PATH |
$HOME $BOOST_BUILD_PATH |
Boost.Build comes with default versions of those files, which can serve as templates for customized versions.
The command line may contain:
Command line arguments specify targets and build request using the following rules.
An argument with either slashes or the "=" symbol specifies a number of build request elements. In the simplest form, it's just a set of properties, separated by slashes, which become a single build request element, for example:
borland/<runtime-link>static
More complex form is used to save typing. For example, instead of
borland/runtime-link=static borland/runtime-link=dynamic
one can use
borland/runtime-link=static,dynamic
Exactly, the conversion from argument to build request elements is performed by (1) splitting the argument at each slash, (2) converting each split part into a set of properties and (3) taking all possible combination of the property sets. Each split part should have the either the form
feature-name=feature-value1[","feature-valueN]*
or, in case of implicit feature
feature-value1[","feature-valueN;]*
and will be converted into property set
<feature-name>feature-value1 .... <feature-name>feature-valueN
For example, the command line
target1 debug gcc/runtime-link=dynamic,static
would cause target called target1 to be rebuilt in debug mode, except that for gcc, both dynamically and statically linked binaries would be created.
All of the Boost.Build options start with the "--" prefix. They are described in the following table.
Table 23.2. Command line options