裂天之刃 mp3:Boost.Build V2 用户手册 - 概述

http://www.cppprog.com/boost_doc/doc/html/bbv2/overview.html#bbv2.advanced.configuration 

Overview 概览

Concepts 概念

Boost.Jam Language  Boost.Jam语言

Configuration 配置

Invocation 调用

Declaring Targets 声明目标

Projects 工程

The Build Process 构建过程

This section will provide the information necessary to create your own projects using Boost.Build. The information provided here is relatively high-level, and the section called “Detailed reference” as well as the on-line help system must be used to obtain low-level documentation (see --help).
这个章节为你提供了使用 Boost.Build 创建工程所需的信息。这里所提供的信息相对比较高层次，要获得底层的信息，则必须使用 “详细参考”一节 以及在线帮助系统。(请见 --help)。

Boost.Build actually consists of two parts - Boost.Jam, a build engine with its own interpreted language, and Boost.Build itself, implemented in Boost.Jam's language. The chain of events when you type bjam on the command line is:
Boost.Build 实际上包含两部分 - Boost.Jam，一个带有解释性语言的构建引擎，和用 Boost.Jam 的语言实现的 Boost.Build 本身。当你在命令行敲入 bjam 时，发生的事件如下：

1. Boost.Jam tries to find Boost.Build and loads the top-level module. The exact process is described in the section called “Initialization”
   Boost.Jam 尝试查找 Boost.Build 并装入顶层模块。精确的过程在 “初始化”一节 中描述。

2. The top-level module loads user-defined configuration files, user-config.jam and site-config.jam, which define available toolsets.
   顶层模块装入用户自定义配置文件，user-config.jam 和 site-config.jam，它们定义了可用的工具集。

3. The Jamfile in the current directory is read. That in turn might cause reading of further Jamfiles. As a result, a tree of projects is created, with targets inside projects.
   读入当前目录中的 Jamfile。然后可能会读入更多的 Jamfiles。结果，一棵由工程中各个目标所组成的工程树被创建。

4. Finally, using the build request specified on the command line, Boost.Build decides which targets should be built, and how. That information is passed back to Boost.Jam, which takes care of actually running commands.
   最后，使用在命令行中指定的构建请求，Boost.Build 决定要构建哪些目标以及如何构建。这些信息被回传给 Boost.Jam，后者负责实际运行命令。

So, to be able to successfully use Boost.Build, you need to know only four things:
所以，要成功地使用 Boost.Build，你只需要知道以下四件事情：

• How to configure Boost.Build
  如何配置 Boost.Build

• How to write declares targets in Jamfiles
  如何在 Jamfiles 中声明目标

• How the build process works
  构建过程是如何工作的
  

• Some Basics about the Boost.Jam language. See the section called “Boost.Jam Language”.
  有关 Boost.Jam 语言的一些基础知识。参见 “Boost.Jam 语言”一节。

 

Concepts 概念

Boost.Build has a few unique concepts that are introduced in this section. The best way to explain the concepts is by comparison with more classical build tools.
Boost.Build 有几个独特的概念，我们在这一节中进行介绍。解释这些概念的最好方法是与其它典型的构建工具进行对比。

When using any flavour of make, you directly specify targets and commands that are used to create them from other target. The below example creates a.o from a.c using a hardcoded compiler invocation command.
使用 make 时，你会直接指定 目标 以及从其它目标构建这些目标时所使用的命令。以下例子就是使用一个硬编码的编译器调用命令从 a.c 生成 a.o.

a.o: a.c
    g++ -o a.o -g a.c

This is rather low-level description mechanism and it's hard to adjust commands, options, and sets of created targets depending on the used compiler and operating system.
这是一种非常底层的描述机制，很难调整其中的命令、选项，而且所生成的目标集依赖于所使用的编译器和操作系统。

To improve portability, most modern build system provide a set of higher-level functions that can be used in build description files. Consider this example:
为提高可移植性，很多现代的构建系统提供了一组高级函数，可在构建描述文件中使用。考虑以下例子：

add_program ("a", "a.c")

This is a function call that creates targets necessary to create executable file from source file a.c. Depending on configured properties, different commands line may be used. However, add_program is higher-level, but rather thin level. All targets are created immediately when build description is parsed, which makes it impossible to perform multi-variant builds. Often, change in any build property requires complete reconfiguration of the build tree.
这是一个函数，声明目标的创建需要从源文件 a.c 生成可执行文件。根据已配置的属性，将使用不同的命令行。虽然 add_program 是较高的层次，但毕竟只是薄薄的一层。当构建描述被分析时，所有目标均被立即创建，这样就不可能执行多个不同构建。通常，任何构建属性的变更都需要完全重新配置整棵构建树。

In order to support true multivariant builds, Boost.Build introduces the concept of metatarget—object that is created when build description is parsed and can be later called with specific build properties to generate actual targets.
为了支持真正的多个不同构建，Boost.Build 引入了概念 元目标metatarget—一个在分析构建描述时生成的对象，它可以在稍后根据指定的构建属性进行调用，以生成实际目标。

Consider an example:
考虑以下例子：

exe a : a.cpp ;

When this declaration is parsed, Boost.Build creates a metatarget, but does not yet decides what files must be created, or what commands must be used. After all build files are parsed, Boost.Build considers properties requested on the command line. Supposed you have invoked Boost.Build with:
当对此描述进行分析时，Boost.Build 创建一个元目标，但尚不决定要创建什么文件，或者要使用什么命令。在所有构建文件都分析完成后，Boost.Build 再考虑命令行中所请求的各种属性。假设你如下执行 Boost.Build：

bjam toolset=gcc toolset=msvc

In that case, the metatarget will be called twice, once with toolset=gcc and once with toolset=msvc. Both invocations will produce concrete targets, that will have different extensions and use different command lines.
这种情况下，元目标将被调用两次，一次带有 toolset=gcc，另一次是带有 toolset=msvc。两次调用都会产生实际的目标，它们有不同的扩展名，并且使用不同的命令行。

Another key concept is build property. Build property is a variable that affects the build process. It can be specified on the command line, and is passed when calling a metatarget. While all build tools have a similar mechanism, Boost.Build differs by requiring that all build properties are declared in advance, and providing a large set of properties with portable semantics.
另一个关键概念是 构建属性build property。构建属性是一个影响构建过程的变量。它可以在命令行中指定，在调用元目标时被传入。虽然所有构建工具都有类似的机制，但是 Boost.Build 的不同之处在于，它要求所有构建属性事先声明，且提供了一大堆具有可移植语义的属性。

The final concept is property propagation. Boost.Build does not require that every metatarget is called with the same properties. Instead, the "top-level" metatargets are called with the properties specified on the command line. Each metatarget can elect to augment or override some properties (in particular, using the requirements mechanism, see the section called “Requirements”). Then, the dependency metatargets are called with modified properties and produce concrete targets that are then used in build process. Of course, dependency metatargets maybe in turn modify build properties and have dependencies of their own.
最后一个概念是 属性传播property propagation。Boost.Build 不要求每个元目标以相同的属性调用。相反，"顶层"的元目标以命令行中指定的属性进行调用。每个元目标可以选择增加或覆盖某些属性(特别地，使用需求机制，请见 “Requirements”一节)。然后，依赖的元目标以修改后的属性进行调用，并生成构建过程中使用的具体目标。当然，依赖元目标也可能反过来修改构建属性，并建立它们自己的依赖。

For more in-depth treatment of the requirements and concepts, you may refer to SYRCoSE 2009 Boost.Build article.
有关需求和概念的进一步深入了解，你可以参考 SYRCoSE 2009 Boost.Build 论文。

Boost.Jam Language  Boost.Jam语言

This section will describe the basics of the Boost.Jam language—just enough for writing Jamfiles. For more information, please see the Boost.Jam documentation.
本节描述 Boost.Jam 语言的基础—仅够用于编写 Jamfiles。更多的信息，请参见 Boost.Jam 文档。

Boost.Jam has an interpreted, procedural language. On the lowest level, a Boost.Jam program consists of variables and rules (the Jam term for function). They are grouped in modules—there's one global module and a number of named modules. Besides that, a Boost.Jam program contains classes and class instances.
Boost.Jam 有一个解释性的过程语言。在最底层，Boost.Jam 程序由变量和 规则 ("函数"一词在 Jam 中的术语)组成。它们组成各个模块—有一个全局模块和多个命名模块。此外，Boost.Jam 程序还包含类和类实例。

Syntantically, a Boost.Jam program consists of two kind of elements—keywords (which have a special meaning to Boost.Jam) and literals. Consider this code:
在语法上，Boost.Jam 程序由两类元素组成—关键字(对于 Boost.Jam 来说具有特殊的意义) 和普通文字。考虑以下代码：

a = b ;

which assigns the value b to the variable a. Here, = and ; are keywords, while a and b are literals.
它将值 b 赋给变量 a。这里，= 和 ; 是关键字，而 a 和 b 是普通文字。

Warning 警告

All syntax elements, even keywords, must be separated by spaces. For example, omitting the space character before ; will lead to a syntax error.

所有语法元素，包括关键字，都必须用空格分隔。例如，省略 ; 前面的空格将导致语法错误。

If you want to use a literal value that is the same as some keyword, the value can be quoted:
如果你想使用一个与某个关键字相同的文字，就要把它用引号引起来：

a = "=" ;

All variables in Boost.Jam have the same type—list of strings. To define a variable one assigns a value to it, like in the previous example. An undefined variable is the same as a variable with an empty value. Variables can be accessed using the $(variable) syntax. For example:
在 Boost.Jam 中的所有变量都具有相同的类型—字符串列表。要定义一个变量同时赋值给它，就象前面的例子那样。一个未定义的变量和一个具有空值的变量一样。变量可以用 $(variable) 语法来访问。例如：

a = $(b) $(c) ;

Rules are defined by specifying the rule name, the parameter names, and the allowed size of the list value for each parameter.
规则通过指定规则名、参数名及各个参数所允许的列表值大小来定义。

rule example
(
parameter1 :
 parameter2 ? :
 parameter3 + :
 parameter4 *
)
{
// body
}

When this rule is called, the list passed as the first argument must have exactly one value. The list passed as the second argument can either have one value of be empty. The two remaining arguments can be arbitrarily long, but the third argument may not be empty.
在调用这个规则时，传入的第一个参数的列表必须刚好包含一个值。第二个参数的列表则可以有一个值或者为空。其余两个参数可以是变长的，但第三个参数不能为空。

The overview of Boost.Jam language statements is given below:
以下是 Boost.Jam 语言的语句的一个概览：

helper 1 : 2 : 3 ;
x = [ helper 1 : 2 : 3 ] ;

This code calls the named rule with the specified arguments. When the result of the call must be used inside some expression, you need to add brackets around the call, like shown on the second line.
这段代码以给定的参数调用命名规则。当调用的结果要在某个表达式中使用时，你必须用方括号把调用括起来，就象前面第二行语句那样。

if cond { statements } [ else { statements } ]

This is a regular if-statement. The condition is composed of:
这是一个普通的 if-语句。条件由以下组成：

• Literals (true if at least one string is not empty)
  普通文字(当至少一个字符串非空时为真)

• Comparisons: a operator b where operator is one of =, !=, <, >, <=, >=. The comparison is done pairwise between each string in the left and the right arguments.
  比较操作：a operator b ，其中 operator 为 =, !=, <, >, <=, >= 之一。比较操作是在左参数和右参数的各个字符串之间成对地进行的。

• Logical operations: ! a, a && b, a || b
  逻辑操作：! a, a && b, a || b

• Grouping: ( cond )
  分组操作：( cond )

 

for var in list { statements }

Executes statements for each element in list, setting the variable var to the element value.
对 list 中的各个元素执行 statements，将变量 var 设为各个元素的值。

while cond { statements }

Repeatedly execute statements while cond remains true upon entry.
当 cond 在每次进入时保持为真时重复执行 statements。

return values ;
 

This statement should be used only inside a rule and assigns values to the return value of the rule.
这个语句只应在某个规则的内部使用，它将 values 赋为该规则的返回值。

Warning 警告

The return statement does not exit the rule. For example:

return 语句不会退出规则。例如：

rule test ( )
{
 if 1 = 1 {
 return "reasonable" ;
 }
 return "strange" ;
}

will return strange, not reasonable.
将返回 strange, 而不是 reasonable.

 

import module ;
import module : rule ;

The first form imports the specified bjam module. All rules from that module are made available using the qualified name: module.rule. The second form imports the specified rules only, and they can be called using unqualified names.
第一种形式导入指定的 bjam 模块。该模块的所有规则都可以通过限定名称 module.rule 使用。第二种形式仅导入指定的规则，该规则可以通过非限定名称调用。

Sometimes, you'd need to specify the actual command lines to be used when creating targets. In jam language, you use named actions to do this. For example:
有时候，你需要在构建目标时指定真实的命令行。在 jam 语言中，你可以用命名动作来实现。例如：

actions create-file-from-another
{
 create-file-from-another $(<) $(>)
}

This specifies a named action called create-file-from-another. The text inside braces is the command to invoke. The $(<) variable will be expanded to a list of generated files, and the $(>) variable will be expanded to a list of source files.
它指定了一个名为 create-file-from-another 的命名动作。在大括号中的文本是要调用的命令。变量 $(<) 将被展开为被生成文件的列表，而变量 $(>) 则被展开为源文件的列表。

To flexibly adjust command line, you can define a rule with the same name as the action, and taking three parameters -- targets, sources and properties. For example:
为了灵活调整命令行，你可以定义一个和该动作同名的规则，它接受三个参数 -- 目标、源和属性。例如：

rule create-file-from-another ( targets * : sources * : properties * )
{
 if debug in $(properties)
 {
 OPTIONS on $(targets) = --debug ;
 }
}
actions create-file-from-another
{
 create-file-from-another $(OPTIONS) $(<) $(>)
}

In this example, the rule checks if certain build property is specified. If so, it sets variable OPIONS that is then used inside the action. Note that the variables set "on a target" will be visible only inside actions building that target, not globally. Were they set globally, using variable named OPTIONS in two unrelated actions would be impossible.
在这个例子中，规则会检查是否指定了特定的构建属性。如果有，则设置变量 OPIONS 然后在动作中使用它。注意，被设置"在特定目标上"的变量仅在构建该目标的动作内可见，而不是全局的。如果它被设为全局的，那么在两个无关的动作中使用名为 OPTIONS 的变量就不可能了。

More details can be found in Jam reference, the section called “ Rules”
更多细节可以在 Jam 参考手册的 “规则”一节 中找到

Configuration 配置

On startup, Boost.Build searches and reads two configuration files: site-config.jam and user-config.jam. The first one is usually installed and maintained by system administrator, and the second is for user to modify. You can edit the one in the top-level directory of Boost.Build installation or create a copy in your home directory and edit the copy. The following table explains where both files are searched.
在启动时，Boost.Build 查找并读入两个配置文件：site-config.jam 和 user-config.jam。第一个文件通常由系统管理员安装并维护，而第二个文件则由用户来修改。你可以在 Boost.Build 安装的顶级目录中编辑一个，或者在你的主目录中创建一份拷贝并编辑它。下表解释了在哪里搜索这两个文件。

Table 32.1. Search paths for configuration files
表 32.1. 配置文件的搜索路径

  site-config.jam user-config.jam Linux

/etc

$HOME

$BOOST_BUILD_PATH

$HOME

$BOOST_BUILD_PATH

Windows

%SystemRoot%

%HOMEDRIVE%%HOMEPATH%

%HOME%

%BOOST_BUILD_PATH%

%HOMEDRIVE%%HOMEPATH%

%HOME%

%BOOST_BUILD_PATH%

Tip 提示

You can use the --debug-configuration option to find which configuration files are actually loaded.
你可以用 --debug-configuration 选项来查找实际导入的是哪个配置议论的。

Usually, user-config.jam just defines available compilers and other tools (see the section called “Targets in site-config.jam” for more advanced usage). A tool is configured using the following syntax:
通常，user-config.jam 只定义可用的编译器和其它工具(更深入的用法请见 “site-config.jam中的目标”一节)。使用以下语法来配置一个工具：

using tool-name : ... ;

The using rule is given a name of tool, and will make that tool available to Boost.Build. For example,
规则 using 给定工具的名字，并使得该工具对 Boost.Build 可用。例如，

using gcc ;

will make the GCC compiler available.
将使得 GCC 编译器可用。

All the supported tools are documented in the section called “Builtin tools”, including the specific options they take. Some general notes that apply to most C++ compilers are below.
所有可支持的工具在 “内建工具”一节 中介绍，包括它们所带的特殊选项。以下是关于多数C++编译器的通用说明。

For all the C++ compiler toolsets Boost.Build supports out-of-the-box, the list of parameters to using is the same: toolset-name, version, invocation-command, and options.
对于 Boost.Build 缺省配置就支持的所有编译器工具集，给 using 的参数列表都是一样的：toolset-name, version, invocation-command, 和 options.

If you have a single compiler, and the compiler executable
如果你只有一个编译器，且编译器的可执行文件

• has its “usual name” and is in the PATH, or
  具有"正常名字"且位于 PATH 中，或者

• was installed in a standard “installation directory”, or
  被安装在标准的"安装目录"下，或者

• can be found using a global system like the Windows registry.
  可以用全局系统，如 Windows 注册表，查找得到。

it can be configured by simply:
它只需如下配置：

using tool-name ;

If the compiler is installed in a custom directory, you should provide the command that invokes the compiler, for example:
如果该编译器安装在一个定制的目录，你就要提供调用该编译器的命令，例如：

using gcc : : g++-3.2 ;
using msvc : : "Z:/Programs/Microsoft Visual Studio/vc98/bin/cl" ;

Some Boost.Build toolsets will use that path to take additional actions required before invoking the compiler, such as calling vendor-supplied scripts to set up its required environment variables. When compiler executables for C and C++ are different, path to the C++ compiler executable must be specified. The “invocation command” can be any command allowed by the operating system. For example:
有些 Boost.Build 工具集要在调用编译器之前用这个路径来进行其它必要的动作，如调用一个厂家提供的脚本来设置所需的环境变量。如果用于 C 和 C++ 的编译程序是不同的，那么必须指定 C++ 编译程序的路径。“invocation command”可以是操作系统允许的任何命令。例如：

using msvc : : echo Compiling && foo/bar/baz/cl ;

will work.
也可以工作。

To configure several versions of a toolset, simply invoke the using rule multiple times:
要配置一个工具集的多个版本，只要多次调用 using 规则即可。

using gcc : 3.3 ;
using gcc : 3.4 : g++-3.4 ;
using gcc : 3.2 : g++-3.2 ;

Note that in the first call to using, the compiler found in the PATH will be used, and there's no need to explicitly specify the command.
注意，在调用第一个 using 时，会使用在 PATH 中找到的编译器，无需明确指定相关命令。

Many of toolsets have an options parameter to fine-tune the configuration. All of Boost.Build's standard compiler toolsets accept four options cflags, cxxflags, compileflags and linkflags as options specifying flags that will be always passed to the corresponding tools. Values of the cflags feature are passed directly to the C compiler, values of the cxxflags feature are passed directly to the C++ compiler, and values of the compileflags feature are passed to both. For example, to configure a gcc toolset so that it always generates 64-bit code you could write:
许多工具集有一个参数 options 用于对配置进行调整。所有 Boost.Build 的标准编译器工具集都用 options 接受四个内建选项 cflags, cxxflags, compileflags 和 linkflags 的属性，以指定传递给对应工具的选项。cflags 特性的值会直接传递给 C 编译器，cxxflags 特性的值则直接传递给 C++ 编译器，而 compileflags 特性的值则传给两者。例如，要将 gcc 工具集进行配置以使之一直生成64位代码，你可以写：

using gcc : 3.4 : : -m64 -m64 ;

Warning 警告

Although the syntax used to specify toolset options is very similar to syntax used to specify requirements in Jamfiles, the toolset options are not the same as features. Don't try to specify a feature value in toolset initialization.
虽然用于指定工具集选项的语法与用于指定 Jamfile 中的需求的语法非常相似，但是工具集选项不同于需求的特性。不要试图在工具集初始化中指定一个特性值。

Invocation 调用

Examples 示例

Options 选项

Properties 属性

Targets 目标

To invoke Boost.Build, type bjam on the command line. Three kinds of command-line tokens are accepted, in any order:
要调用 Boost.Build，在命令行中打入 bjam。可以接受三种命令行记号，顺序任意：

options 选项

Options start with either dash, or two dashes. The standard options are listed below, and each project may add additional options
选项以一个或两个减号开始。下面会列出所有标准的选项，每个工程可以增加额外的选项

properties 属性

Properties specify details of what you want to build (e.g. debug or release variant). Syntactically, all command line tokens with equal sign in them are considered to specify properties. In the simplest form, property looks like feature=value
属性指定了你想要构建的细节(如调试版还是发布版)。语法上，所有带等号的命令行记号都会被视为指定了属性。最简单的形式是 feature=value

target 目标

All tokens that are neither options nor properties specify what targets to build. The available targets entirely depend on the project you are building.
所有既不是选项也不是属性的记号指定了要构建哪些目标。有效的目标完全依赖于你要构建的工程。

Examples 示例

To build all targets defined in Jamfile in the current directory with default properties, run:
要以缺省属性构建当前目录的 Jamfile 中的所有目标，运行：

bjam

To build specific targets, specify them on the command line:
要构建特定目标，则在命令行中指定它们：

bjam lib1 subproject//lib2

To request a certain value for some property, add property=value to the command line:
要为某些属性指定特定值，则在命令行中加入 property=value ：

bjam toolset=gcc variant=debug optimization=space

Options 选项

Boost.Build recognizes the following command line options.
Boost.Build 使用以下命令行选项：

--help

Invokes the online help system. This prints general information on how to use the help system with additional --help* options.
调用在线帮助系统。要输出如何使用帮助系统的信息，请使用额外的 --help* 选项。

--clean

Cleans all targets in the current directory and in any subprojects. Note that unlike the clean target in make, you can use --clean together with target names to clean specific targets.
清除当前目录及所有子工程中的目标。注意，与 make 中的 clean 目标不同，你可以将 --clean 和目标名一起使用以清除指定目标。

--clean-all

Cleans all targets, no matter where they are defined. In particular, it will clean targets in parent Jamfiles, and targets defined under other project roots.
清除所有目标，不管它们在哪里定义。特定地，它将清除在父 Jamfiles 中的目标以及定义在其它工程根下的目标。

--build-dir

Changes build directories for all project roots being built. When this option is specified, all Jamroot files should declare project name. The build directory for the project root will be computed by concatanating the value of the --build-dir option, the project name specified in Jamroot, and the build dir specified in Jamroot (or bin, if none is specified).
为被构建的所有工程根修改构建目录。如果指定了这一选项，所有 Jamroot 文件都应声明工程名。工程根的构建目录通过将 --build-dir 选项的值与在 Jamroot 中指定的工程名以及在 Jamroot 中指定的构建目录(如果没有指定则为 bin) 相联接得到，

The option is primarily useful when building from read-only media, when you can't modify Jamroot.
该选项主要在从只读介质进行构建时使用，这时你不能修改 Jamroot。

--version

Prints information on Boost.Build and Boost.Jam versions.
打印 Boost.Build 和 Boost.Jam 的版本信息。

-a

Causes all files to be rebuilt.
重建所有文件。

-n

Do no execute the commands, only print them.
不执行命令，仅输出命令。

-d+2

Show commands as they are executed.
显示命令，就象它们被执行一样。

-d0

Supress all informational messages.
禁止所有信息。

-q

Stop at first error, as opposed to continuing to build targets that don't depend on the failed ones.
在第一个错误处停止，不再继续构建那些不依赖该错误的目标。

-j N

Run up to N commands in parallel.
并发运行至多 N 个命令。

--debug-configuration

Produces debug information about loading of Boost.Build and toolset files.
产生关于 Boost.Build 和工具集文件装入的调试信息。

--debug-building

Prints what targets are being built and with what properties.
打印正在构建的目标和所带的属性。

--debug-generators

Produces debug output from generator search process. Useful for debugging custom generators.
从生成器查找过程产生调试输出。用于调试客户化的生成器。

--ignore-config

Do not load site-config.jam and user-config.jam configuration files.
不要装入 site-config.jam 和 user-config.jam 配置文件。

Properties 属性

In the simplest case, the build is performed with a single set of properties, that you specify on the command line with elements in the form feature=value. The complete list of features can be found in the section called “Builtin features”. The most common features are summarized below.
在最简单的情况下，构建是以单个属性集执行的，即你在命令行中以形如 feature=value 的元素所指定的属性集。特性的完整列表可以在 “内建特性”一节 中找到。以下是最常用的特性。

Table 32.2. 
表 32.2. 

Feature 特性 Allowed values 可用值 Notes 说明 variant debug,release   link shared,static Determines if Boost.Build creates shared or static libraries
决定 Boost.Build 是否创建共享或静态库 threading single,multi Cause the produced binaries to be thread-safe. This requires proper support in the source code itself.
生成的二进制文件是线程安全的。这一要求应在源码本身上正确支持。 address-model 32,64 Explicitly request either 32-bit or 64-bit code generation. This typically requires that your compiler is appropriately configured. Please refer to the section called “C++ Compilers” and your compiler documentation in case of problems.
显式要求生成32位或64位代码。这明确要求你的编译器是正确配置的。如有问题请参考 “C++ 编译器”一节 及你的编译器文档。 toolset (Depends on configuration) The C++ compiler to use. See the section called “C++ Compilers” for a detailed list.
使用的 C++ 编译器。详细列表请见 “C++编译器” 一节。 includes (Arbitrary string) Additional include paths for C and C++ compilers.
用于C和C++编译器的额外包含路径。 define (Arbitrary string) Additional macro definitions for C and C++ compilers. The string should be either SYMBOL or SYMBOL=VALUE
用于C和C++编译器的额外宏定义。该字符串应为 SYMBOL 或 SYMBOL=VALUE cxxflags (Arbitrary string) Custom options to pass to the C++ compiler.
定制传递给C++编译器的选项。 cflags (Arbitrary string) Custom options to pass to the C compiler.
定制传递给C编译器的选项。 linkflags (Arbitrary string) Custom options to pass to the C++ linker.
定制传递给C++链接器的选项。 runtime-link shared,static Determines if shared or static version of C and C++ runtimes should be used.
决定使用C和C++运行时库的共享版本还是静态版本。

If you have more than one version of a given C++ toolset (e.g. configured in user-config.jam, or autodetected, as happens with msvc), you can request the specific version by passing toolset-version as the value of the toolset feature, for example toolset=msvc-8.0.
如果你的C++工具集有超过一个版本(如：在 user-config.jam 中配置的，或者象 msvc 那样自动检测到的)，你可以将 toolset-version 作为 toolset 特性的值传递，以指定版本，例如 toolset=msvc-8.0.

If a feature has a fixed set of values it can be specified more than once on the command line. In which case, everything will be built several times -- once for each specified value of a feature. For example, if you use
如果一个特性有一个固定的值集合，它就可以在命令行中多次指定。这种情况下，每样东西都会多次构建 -- 该特性的每个指定值构建一次。例如，如果你用

bjam link=static link=shared threading=single threading=multi

Then a total of 4 builds will be performed. For convenience, instead of specifying all requested values of a feature in separate command line elements, you can separate the values with commands, for example:
则总共执行4次构建。为方便起见，无需在独立的命令行元素中指定所请求的值，你可以用逗号分离各个值，例如：

bjam link=static,shared threading=single,multi

The comma has special meaning only if the feature has a fixed set of values, so
仅当特性具有固定的值集合时，逗号才有特定意义，因此

bjam include=static,shared

is not treated specially.
不会被特别对待。

Targets 目标

All command line elements that are neither options nor properties are the names of the targets to build. See the section called “Target identifiers and references”. If no target is specified, the project in the current directory is built.
所有既不是选项也不是属性的命令行元素就是要构建的目标名。请见 “目标标识符和引用”一节。如果未指定目标，则构建当前目录中的工程。

Declaring Targets 声明目标

Name 名称

Sources 源

Requirements 要求

Default Build 缺省构建

Additional Information 额外信息

A Main target is a user-defined named entity that can be built, for example an executable file. Declaring a main target is usually done using one of the main target rules described in the section called “Builtin rules”. The user can also declare custom main target rules as shown in the section called “Main target rules”.
主目标 是指用户定义的一个可构建的命名实体，例如一个可执行文件。主目标通常是通过使用在 “内建规则”一节 中描述的主目标规则之一来声明的。用户也可以象在 “主目标规则”一节 中所说的那样声明定制的主目标规则。

Most main target rules in Boost.Build have the same common signature:
Boost.Build 中多数主目标规则都具有相同的公用签名：

rule rule-name (
 main-target-name :
 sources + :
 requirements * :
 default-build * :
 usage-requirements * )

• main-target-name is the name used to request the target on command line and to use it from other main targets. A main target name may contain alphanumeric characters, dashes (‘-’), and underscores (‘_’).
  main-target-name 是用于在命令行请求该目标以及从其它主目标使用的名字。主目标名可以包含字母、连字符 (‘-’) 和下划线 (‘_’)。
• sources is the list of source files and other main targets that must be combined.
  sources 是源文件列表以及其它必须组合的主目标。
• requirements is the list of properties that must always be present when this main target is built.
  requirements 是在构建主目标时必须一直使用的属性的列表。
• default-build is the list of properties that will be used unless some other value of the same feature is already specified, e.g. on the command line or by propagation from a dependent target.
  default-build 也是将被使用的属性的列表，除非这些特性的值被通过命令行指定或从依赖目标传播得到。
• usage-requirements is the list of properties that will be propagated to all main targets that use this one, i.e. to all its dependents.
  usage-requirements 是一些属性的列表，这些属性将被传播至所有依赖于该目标的主目标。

Some main target rules have a different list of parameters as explicitly stated in their documentation.
有些主目标规则具有不同的参数列表，将在它们的文档中明确说明。

The actual requirements for a target are obtained by refining requirements of the project where a target is declared with the explicitly specified requirements. The same is true for usage-requirements. More details can be found in the section called “Property refinement”
一个目标的实际要求是通过对声明该目标的工程的要求和显式指定的要求一起精化而得到的。对于 usage-requirements 也一样。更多细节可以在 “属性精化”一节 中找到。

Name 名称

The name of main target has two purposes. First, it's used to refer to this target from other targets and from command line. Second, it's used to compute the names of the generated files. Typically, filenames are obtained from main target name by appending system-dependent suffixes and prefixes.
主目标的名称有两个目的。首先，它用于在其它目标或命令行中指称该目标。其次，它用于计算生成文件的名字。通常，文件名由主目标名字加上系统相关的前缀和后缀而成。

The name of a main target can contain alphanumeric characters, dashes, undescores and dots. The entire name is significant when resolving references from other targets. For determining filenames, only the part before the first dot is taken. For example:
主目标名称可以包含字母、连字符、下划线和点符。在从其它目标进行引用解释时使用完整的名称。而在生成文件名时，则只使用第一个点符之前的部分。例如：

obj test.release : test.cpp : release ;
obj test.debug : test.cpp : debug ;

will generate two files named test.obj (in two different directories), not two files named test.release.obj and test.debug.obj.
将生成两个名为 test.obj 的文件(在不同的目录下)，而不是两个分别名为 test.release.obj 和 test.debug.obj 的文件。

Sources 源

The list of sources specifies what should be processed to get the resulting targets. Most of the time, it's just a list of files. Sometimes, you'll want to automatically construct the list of source files rather than having to spell it out manually, in which case you can use the glob rule. Here are two examples:
源列表指明了要得到结果目标应处理些什么。多数时候，它只是一个文件列表。有时，你可能想自动构造源文件的列表，而不是手工将它拼写出来，这时你可以使用 glob 规则。以下是两个例子：

exe a : a.cpp ; # a.cpp is the only source file a.cpp 是唯一的源文件
exe b : [ glob *.cpp ] ; # all .cpp files in this directory are sources 目录中所有 .cpp 文件都是源

Unless you specify a file with an absolute path, the name is considered relative to the source directory?—?which is typically the directory where the Jamfile is located, but can be changed as described in the section called “Projects”.
除非你以绝对路径来指明文件，否则文件名被认为是相对于源目录的?—?通常是 Jamfile 所在的目录，但是也可以被修改，见 “工程”一节。

The list of sources can also refer to other main targets. Targets in the same project can be referred to by name, while targets in other projects must be qualified with a directory or a symbolic project name. The directory/project name is separated from the target name by a double forward slash. There's no special syntax to distinguish the directory name from the project name—the part before the double slash is first looked up as project name, and then as directory name. For example: 
源列表也可以引向其它主目标。在同一个工程中的目标可以用名字来引用，而在其它工程中的目标则必须用一个目录或工程符号名来限定。目录/工程名与目标名之间以一个双重斜杠分隔。没有特殊的语法来区分目录名和工程名—双斜杠前的部分先按工程名查找，再按目录名查找。例如：

lib helper : helper.cpp ;
exe a : a.cpp helper ;
# Since all project ids start with slash, ".." is directory name.
exe b : b.cpp ..//utils ;
exe c : c.cpp /boost/program_options//program_options ;

The first exe uses the library defined in the same project. The second one uses some target (most likely library) defined by Jamfile one level higher. Finally, the third target uses some C++ Boost library, referring to it by absolute symbolic name. More information about target references can be found in the section called “Dependent Targets” and the section called “Target identifiers and references”.
第一个 exe 使用在本工程中定义的库。第二个则使用在上一级 Jamfile 定义的某个目标(很可能是库)。最后，第三个目标使用了某个 C++ Boost 库，以绝对符号名称来引用。有关目标引用的更多信息，可以在 “依赖目标”一节 和 “目标标识符和引用”一节 中找到。

Requirements 要求

Requirements are the properties that should always be present when building a target. Typically, they are includes and defines:
要求是指在构建一个目标时要一直使用的属性。典型地，它们是一些包含和定义：

exe hello : hello.cpp : /opt/boost MY_DEBUG ;

There is a number of other features, listed in the section called “Builtin features”. For example if a library can only be built statically, or a file can't be compiled with optimization due to a compiler bug, one can use
还有多个其它的特性，列在 “内建特性”一节 中。例如，如果一个库只能静态构建，或者一个文件由于编译器缺陷而不能以优化方式编译，你可以使用：

lib util : util.cpp : static ;
obj main : main.cpp : off ;

 

Sometimes, particular relationships need to be maintained among a target's build properties. This can be achieved with conditional requirements. For example, you might want to set specific #defines when a library is built as shared, or when a target's release variant is built in release mode.
有时，有些特定的关系也需要在目标的构建属性中维护。这时可以使用 条件要求。例如，你可能想在某个库以动态方式构建时设置特定的 #defines，或者在某个目标的 release 版本按发布模式构建时。

lib network : network.cpp
 : shared:NEWORK_LIB_SHARED
release:EXTRA_FAST
;

In the example above, whenever network is built with shared, NEWORK_LIB_SHARED will be in its properties, too.
在上例中，当 network 以 shared 构建时，NEWORK_LIB_SHARED 将成为它的属性之一。

You can use several properties in the condition, for example:
你可以在条件中使用多个属性，例如：

lib network : network.cpp
 : gcc,speed:USE_INLINE_ASSEMBLER
 ;

 

A more powerful variant of conditional requirements is indirect conditional requirements. You can provide a rule that will be called with the current build properties and can compute additional properties to be added. For example:
条件要求的一个更为强大的变体是 间接条件要求。你可以提供一个规则，以当前的构建属性来调用它，计算得到要增加的其它属性。例如：

lib network : network.cpp
 : @my-rule
 ;
rule my-rule ( properties * )
{
 local result ;
 if gcc speed in $(properties)
 {
 result += USE_INLINE_ASSEMBLER ;
 }
 return $(result) ;
}

This example is equivalent to the previous one, but for complex cases, indirect conditional requirements can be easier to write and understand.
这个例子和上一个效果一样，但是对于复杂的情形，间接条件要求更易于编写，也更易懂。

Requirements explicitly specified for a target are usually combined with the requirements specified for the containing project. You can cause a target to completely ignore specific project's requirement using the syntax by adding a minus sign before a property, for example:
为一个目标显式指定的要求通常要与其所在工程所指定的要求相合并。你可以在某个属性之前加上一个减号，让目标完全忽略工程所指定的要求，例如：

exe main : main.cpp : -UNNECESSARY_DEFINE ;

This syntax is the only way to ignore free properties from a parent, such as defines. It can be also useful for ordinary properties. Consider this example:
这种语法是忽略来自于父工程的自由属性(如定义)的唯一方法。它也可以用于普通属性。考虑以下例子：

project test : requirements multi ;
exe test1 : test1.cpp ;
exe test2 : test2.cpp : single ;
exe test3 : test3.cpp : -multi ;

Here, test1 inherits project requirements and will always be built in multi-threaded mode. The test2 target overrides project's requirements and will always be built in single-threaded mode. In contrast, the test3 target removes a property from project requirements and will be built either in single-threaded or multi-threaded mode depending on which variant is requested by the user.
这里，test1 继承了工程要求，将总是按多线程模式构建。而目标 test2 则 覆写 了工程的要求，将总是按单线程模式构建。相比之下，目标 test3 去除 了工程要求的一个属性，它根据用户的请求来按单线程或多线程模式构建。

Note that the removal of requirements is completely textual: you need to specify exactly the same property to remove it.
注意，要求的去除需要完整的文字：你必须正确地给出要去除的相同属性。

Default Build 缺省构建

The default-build parameter is a set of properties to be used if the build request does not otherwise specify a value for features in the set. For example:
参数 default-build 是一组这样的属性，如果构建请求中没有指定该组中某个特性的值，就使用这个属性。例如：

exe hello : hello.cpp : : multi ;

would build a multi-threaded target unless the user explicitly requests a single-threaded version. The difference between requirements and default-build is that requirements cannot be overridden in any way.
将构建一个多线程的目标，除非用户明确指定要一个单线程版本。要求和缺省构建之间的区别在于，要求是不能被覆写的。

Additional Information 额外信息

The ways a target is built can be so different that describing them using conditional requirements would be hard. For example, imagine that a library actually uses different source files depending on the toolset used to build it. We can express this situation using target alternatives:
构建目标的方式可以很不一样，用条件要求来描述可能会有困难。例如，想象一个库，它根据构建时所用的工具集来实际选用不同的源文件。我们可以用 目标选择 来表示这种情形：

lib demangler : dummy_demangler.cpp ; # alternative 1
lib demangler : demangler_gcc.cpp : gcc ; # alternative 2
lib demangler : demangler_msvc.cpp : msvc ; # alternative 3

In the example above, when built with gcc or msvc, demangler will use a source file specific to the toolset. Otherwise, it will use a generic source file, dummy_demangler.cpp.
在上例中，如果用 gcc 或 msvc 来构建，则 demangler 将使用指定给相应工具集的源文件。否则，它使用通用的源文件 dummy_demangler.cpp.

It is possible to declare a target inline, i.e. the "sources" parameter may include calls to other main rules. For example:
可以内联地声明一个目标，即参数 "sources" 可以包含对其它主规则的调用。例如：

exe hello : hello.cpp
 [ obj helpers : helpers.cpp : off ] ;

Will cause "helpers.cpp" to be always compiled without optimization. When referring to an inline main target, its declared name must be prefixed by its parent target's name and two dots. In the example above, to build only helpers, one should run bjam hello..helpers.
将使得 "helpers.cpp" 总是非优化地编译。在引用一个内联的主目标时，它的声明名称必须用它的父目标名称和两个点符作为前缀。在上例中，如果要只构建 helpers，你应该运行 bjam hello..helpers.

When no target is requested on the command line, all targets in the current project will be built. If a target should be built only by explicit request, this can be expressed by the explicit rule:
如果在命令行中没有指定目标，则当前工程中的所有目标都将被构建。如果某个目标只能通过显式请求构建，则可以用 explicit 规则实现：

explicit install_programs ;

 

Projects 工程

As mentioned before, targets are grouped into projects, and each Jamfile is a separate project. Projects are useful because they allow us to group related targets together, define properties common to all those targets, and assign a symbolic name to the project that can be used in referring to its targets.
如前所述，目标是被组织到工程中的，每一个 Jamfile 是一个独立的工程。工程是非常有用的，因为它允许我们将相关联的目标组织在一起，定义对所有目标通用的属性，并赋予目标一个符号名称，以便用于对其目标的引用。

Projects are named using the project rule, which has the following syntax:
工程是用 project 规则来命名的，具有以下语法：

project id : attributes ;

Here, attributes is a sequence of rule arguments, each of which begins with an attribute-name and is followed by any number of build properties. The list of attribute names along with its handling is also shown in the table below. For example, it is possible to write:
这里的 attributes 是一个规则参数列表，其中每一个都是以属性名开头，后跟任意数量的构建属性。属性名列表及其处理在后文的表中列出。例如，你可以写：

project tennis
 : requirements multi
 : default-build release
 ;

The possible attributes are listed below.
可用的属性列出如下：

Project id is a short way to denote a project, as opposed to the Jamfile's pathname. It is a hierarchical path, unrelated to filesystem, such as "boost/thread". Target references make use of project ids to specify a target.
Project id 是表示工程的一个缩写，与 Jamfile 的路径名相反。它是一个分级路径，与文件系统无关，例如 "boost/thread"。目标引用 使用 project id 来指定一个目标。

Source location specifies the directory where sources for the project are located.
Source location 指定该工程的源文件所在的目录。

Project requirements are requirements that apply to all the targets in the projects as well as all subprojects.
Project requirements 是应用于该工程及所有子工程的所有目标的要求。

Default build is the build request that should be used when no build request is specified explicitly.
Default build 是在未明确指定构建请求时使用的构建请求。

The default values for those attributes are given in the table below.
这些属性的缺省值在下表中给出。

Table 32.3. 
表 32.3.

Attribute
属性 Name
名字 Default value
缺省值 Handling by the project rule
project 规则的处理 Project id none
无 none
无 Assigned from the first parameter of the 'project' rule. It is assumed to denote absolute project id.
从 'project' 规则的第一个参数赋值。它被假定为表示绝对的 project id。 Source location source-location The location of jamfile for the project
本工程的 jamfile 的位置 Sets to the passed value
设置为传入的值。 Requirements requirements The parent's requirements
父工程的要求 The parent's requirements are refined with the passed requirement and the result is used as the project requirements.
将父工程的要求和传入的要求精化，结果作为工程要求。 Default build default-build none
无 Sets to the passed value
设置为传入的值。 Build directory build-dir Empty if the parent has no build directory set. Otherwise, the parent's build directory with the relative path from parent to the current project appended to it.
如果父工程没有 build directory 设置则为空。否则，为父工程的构建目录加上从父工程到本工程的相对路径。 Sets to the passed value, interpreted as relative to the project's location.
设置为传入的值，按相对于工程位置进行解释。

Besides defining projects and main targets, Jamfiles often invoke various utility rules. For the full list of rules that can be directly used in Jamfile see the section called “Builtin rules”.
除了定义工程和主目标之外，Jamfiles 通常还调用一些工具规则。有关可以在 Jamfile 中直接使用的规则的完整列表，请见 “内建规则”一节。

Each subproject inherits attributes, constants and rules from its parent project, which is defined by the nearest Jamfile in an ancestor directory above the subproject. The top-level project is declared in a file called Jamroot rather than Jamfile. When loading a project, Boost.Build looks for either Jamroot or Jamfile. They are handled identically, except that if the file is called Jamroot, the search for a parent project is not performed.
各子工程会继承来自于父工程的属性、常量和规则，它们是由子工程的一个最近的父目录的 Jamfile 所定义的。顶层的工程由一个名为 Jamroot 的文件声明，而不是 Jamfile。在装入一个工程时，Boost.Build 查找 Jamroot 或 Jamfile。它们的处理方式是一样的，除了一点，如果文件名为 Jamroot，则不再查找父工程。

Even when building in a subproject directory, parent project files are always loaded before those of their subprojects, so that every definition made in a parent project is always available to its children. The loading order of any other projects is unspecified. Even if one project refers to another via the use-project or a target reference, no specific order should be assumed.
即使是在一个子工程目录中进行构建，父工程的文件也会在装入子工程文件之前被装入，这样在父工程中的每个定义对于子工程来说都是可用的。而其它工程的装入顺序则是未指定的。即便一个工程通过 use-project 或目标引用来引用了另一个工程，也不能假定某个特定顺序。

Note 说明

Giving the root project the special name “Jamroot” ensures that Boost.Build won't misinterpret a directory above it as the project root just because the directory contains a Jamfile.

为根工程给定一个特殊的名称 “Jamroot”，可以确保 Boost.Build 不会由于更上一层的目录中含有 Jamfile 而误以为上层的目录才是工程的根。

The Build Process 构建过程

Build Request 构建请求

Building a main target 构建一个主目标

Building a Project 构建一个工程

When you've described your targets, you want Boost.Build to run the right tools and create the needed targets. This section will describe two things: how you specify what to build, and how the main targets are actually constructed.
当你完成了对目标的描述，你就会希望 Boost.Build 可以运行正确的工具来创建所需的目标。这一节将讲述两件事：你如何指定要构建什么，以及主目标实际上是如何被构造的。

The most important thing to note is that in Boost.Build, unlike other build tools, the targets you declare do not correspond to specific files. What you declare in a Jamfile is more like a “metatarget.” Depending on the properties you specify on the command line, each metatarget will produce a set of real targets corresponding to the requested properties. It is quite possible that the same metatarget is built several times with different properties, producing different files.
要留意的最重要的事情是，在 Boost.Build 中，和其它构建工具不同，你所声明的目标并不对应于特定的文件。你在  Jamfile 中所声明的东西类似于一个“元目标”。根据你在命令行中指定的属性，各元目标会生成一组与请求属性相对应的真实目标。同一个元目标很有可能被按不同的属性多次构建，生成不同的文件。

Tip 提示

This means that for Boost.Build, you cannot directly obtain a build variant from a Jamfile. There could be several variants requested by the user, and each target can be built with different properties.
这意味着，对于 Boost.Build，你不能从一个 Jamfile 直接得到一个构建体。用户可以请示多个构建体，各个目标可以按不同属性构建。

Build Request 构建请求

The command line specifies which targets to build and with which properties. For example:
命令行指定了构建哪一个目标和按哪些属性构建。例如：

bjam app1 lib1//lib1 toolset=gcc variant=debug optimization=full

would build two targets, "app1" and "lib1//lib1" with the specified properties. You can refer to any targets, using target id and specify arbitrary properties. Some of the properties are very common, and for them the name of the property can be omitted. For example, the above can be written as:
将按指定属性构建两个目标，"app1" 和 "lib1//lib1"。你可以用 target id 指定任何目标，并指定不同的属性。有些属性很常用，这些属性的名字可以省略。例如，上一个例子可以写为：

bjam app1 lib1//lib1 gcc debug optimization=full

The complete syntax, which has some additional shortcuts, is described in the section called “Invocation”. 
完整的语法以及一些其它缩写，在 "调用"一节 中讲述。

Building a main target 构建一个主目标

When you request, directly or indirectly, a build of a main target with specific requirements, the following steps are done. Some brief explanation is provided, and more details are given in the section called “Build process”.
当你直接或间接地请求按指定要求构建一个主目标时，将执行以下步骤。这里给出一些简要的解释，更多细节请见 “构建过程”一节。

1. Applying default build. If the default-build property of a target specifies a value of a feature that is not present in the build request, that value is added.
   应用缺省构建。如果一个目标的 default-build 属性中所指定的某个特性值没有在构建请求中出现，则加上该值。

2. Selecting the main target alternative to use. For each alternative we look how many properties are present both in alternative's requirements, and in build request. The alternative with large number of matching properties is selected.
   进行主目标选择。对于每一种选择，我们查看有多少属性在选择要求和构建请求中都出现。具有最多匹配属性的选择将被选中。

3. Determining "common" properties. The build request is refined with target's requirements. The conditional properties in requirements are handled as well. Finally, default values of features are added.
   确定"通用"属性。构建请求要按目标要求 精化。在要求中的条件属性也同样被处理。最后，加上特性的缺省值。

4. Building targets referred by the sources list and dependency properties. The list of sources and the properties can refer to other target using target references. For each reference, we take all propagated properties, refine them by explicit properties specified in the target reference, and pass the resulting properties as build request to the other target.
   构建由源列表和依赖关系属性所涉及的目标。源列表和属性可以通过 目标引用 引向其它目标。对于每一个引用，我们接受所有 传播进来的 属性，将它们与在目标引用中指定的显式属性进行精化，并将所得到的结果属性作为构建请求传递给另一个目标。

5. Adding the usage requirements produced when building dependencies to the "common" properties. When dependencies are built in the previous step, they return both the set of created "real" targets, and usage requirements. The usage requirements are added to the common properties and the resulting property set will be used for building the current target.
   将在构建依赖关系过程中生成的使用要求加入到"通用"属性中。当上一步的依赖关系构建完成后，将返回要创建的"真实"目标集，以及使用要求。使用要求被加入到通用属性中，得到的结果属性集将被用于构建当前目标。

6. Building the target using generators. To convert the sources to the desired type, Boost.Build uses "generators" --- objects that correspond to tools like compilers and linkers. Each generator declares what type of targets it can produce and what type of sources it requires. Using this information, Boost.Build determines which generators must be run to produce a specific target from specific sources. When generators are run, they return the "real" targets.
   用生成器构建目标。为了将源文件转换为所期望的类型，Boost.Build 使用了"生成器" --- 与工具相对应的对象，如编译器和链接器。每个生成器声明了它可以生成的目标类型以及它所要求的源类型。通过使用这些信息，Boost.Build 决定要运行哪些生成器来从指定源生成指定目标。当生成器运行完成，它将返回"真实"的目标。

7. Computing the usage requirements to be returned. The conditional properties in usage requirements are expanded and the result is returned.
   计算被返回的使用要求。在使用要求中的条件属性被展开并返回结果。

 

Building a Project 构建一个工程

Often, a user builds a complete project, not just one main target. In fact, invoking bjam without arguments builds the project defined in the current directory.
通常，用户会构建一个完整的工程，而不仅仅是某个主目标。实际上，不带参数调用 bjam 将构建在当前目标中所定义的工程。

When a project is built, the build request is passed without modification to all main targets in that project. It's is possible to prevent implicit building of a target in a project with the explicit rule:
在构建一个工程时，构建请求将不作修改地传递给工程中的所有目标。你可以用 explicit 规则阻止工程中的的某个目标被隐式构建：

explicit hello_test ;

would cause the hello_test target to be built only if explicitly requested by the user or by some other target.
这将使得目标 hello_test 只有在用户或其它目标明确要求时才被构建。

The Jamfile for a project can include a number of build-project rule calls that specify additional projects to be built.
一个工程的 Jamfile 可以包含多个 build-project 规则来调用其它特定工程的构建。

( # )