diff --git a/v2/doc/src/tutorial.xml b/v2/doc/src/tutorial.xml
index bb7c7d059..ac4b21717 100644
--- a/v2/doc/src/tutorial.xml
+++ b/v2/doc/src/tutorial.xml
@@ -16,74 +16,70 @@
sections.
-->
- This section will guide you though the most basic features of
- Boost.Build V2. We will start with the “Hello, world” example,
- learn how to use libraries, and finish with testing and installing features.
+
+ This section will guide you though the most basic features of Boost.Build
+ V2. We will start with the “Hello, world” example, learn how
+ to use libraries, and finish with testing and installing features.
Hello, world
- The simplest project that Boost.Build can construct is
- stored in example/hello/ directory. The
- project is described by a file
- called Jamroot that contains:
+
+ The simplest project that Boost.Build can construct is stored in
+ example/hello/ directory. The project is described by
+ a file called Jamroot that contains:
exe hello : hello.cpp ;
- Even with this simple setup, you can do some interesting
- things. First of all, just invoking bjam will
- build the hello
- executable by compiling and
- linking hello.cpp. By default, debug variant
- is built. Now, to build the
- release variant of hello, invoke
+ Even with this simple setup, you can do some interesting things. First of
+ all, just invoking bjam will build the hello
+ executable by compiling and linking hello.cpp
+ . By default, debug variant is built. Now, to build the release
+ variant of hello, invoke
bjam release
- Note that debug and release variants are created in different
- directories, so you can switch between variants or even build
- multiple variants at once, without any unnecessary
- recompilation. Let's extend the example by adding another line
- to our project's Jamroot:
+ Note that debug and release variants are created in different directories,
+ so you can switch between variants or even build multiple variants at
+ once, without any unnecessary recompilation. Let us extend the example by
+ adding another line to our project's Jamroot:
exe hello2 : hello.cpp ;
- Now let us build both the debug and release variants of our project
- again:
+ Now let us build both the debug and release variants of our project again:
bjam debug release
- Note that two variants of hello2 are linked.
- Since we have already built both variants
- of hello, hello.cpp won't be recompiled;
- instead the existing object files will just be linked into the
- corresponding variants of hello2. Now
- let's remove all the built products:
+ Note that two variants of hello2 are linked. Since we
+ have already built both variants of hello, hello.cpp
+ will not be recompiled; instead the existing object files will just be
+ linked into the corresponding variants of hello2. Now
+ let us remove all the built products:
bjam --clean debug release
- It's also possible to build or clean specific targets. The
- following two commands, respectively, build or clean only the
- debug version of hello2.
+ It is also possible to build or clean specific targets. The following two
+ commands, respectively, build or clean only the debug version of
+ hello2.
bjam hello2
bjam --clean hello2
-
+
Properties
@@ -97,46 +93,49 @@ bjam --clean hello2
value) pair. When a user initiates a build, Boost.Build
automatically translates the requested properties into appropriate
command-line flags for invoking toolset components like compilers
- and linkers.
+ and linkers.
+
- There are many built-in features that can be combined to
+
+ There are many built-in features that can be combined to
produce arbitrary build configurations. The following command
builds the project's release variant with inlining
disabled and debug symbols enabled:
-
bjam release inlining=off debug-symbols=on
-
+
- Properties on the command-line are specified with the syntax:
+
+ Properties on the command-line are specified with the syntax:
feature-name=feature-value
-
+
- The and that we've seen
- in bjam invocations are just a shorthand way to
- specify values of the variant feature. For example, the command
- above could also have been written this way:
+
+ The and that we have seen
+ in bjam invocations are just a shorthand way to specify
+ values of the variant feature. For example, the
+ command above could also have been written this way:
bjam variant=release inlining=off debug-symbols=on
- variant is so commonly-used that it has
- been given special status as an implicit
- feature—Boost.Build will deduce the its identity just
- from the name of one of its values.
+
+ variant is so commonly-used that it has been given
+ special status as an implicit feature—
+ Boost.Build will deduce the its identity just from the name of one of its
+ values.
A complete description of features can be found in .
-
Build Requests and Target Requirements
@@ -145,19 +144,19 @@ bjam variant=release inlining=off debug-symbols=on
a build request—a description of
the desired properties for building the requested targets (or,
if no targets were explicitly requested, the project in the
- current directory). The actual
+ current directory). The actual
properties used for building targets are typically a
combination of the build request and properties derived from
the project's Jamroot (and its other
Jamfiles, as described in ). For example, the
+ linkend="bbv2.tutorial.hierarchy"/>). For example, the
locations of #included header files are normally
not specified on the command-line, but described in
Jamfiles as target
requirements and automatically combined with the
- build request for those targets. Multithread-enabled
+ build request for those targets. Multithread-enabled
compilation is another example of a typical target
- requirement. The Jamfile fragment below
+ requirement. The Jamfile fragment below
illustrates how these requirements might be specified.
@@ -169,41 +168,39 @@ exe hello
- When hello is built, the two
- requirements specified above will always be present.
- If the build request given on the bjam
- command-line explictly contradicts a target's requirements,
- the target requirements usually override (or, in the case of
- “free”” features like
+ When hello is built, the two requirements specified
+ above will always be present. If the build request given on the
+ bjam command-line explictly contradicts a target's
+ requirements, the target requirements usually override (or, in the case
+ of “free”” features like
<include>,
-
-See
-
+
+ See
+
+
augments) the build request.
-
- The value of the <include> feature is
- relative to the location of Jamroot where it's
+
+ The value of the <include> feature is
+ relative to the location of Jamroot where it is
used.
-
+
Project Attributes
- If we want the same requirements for our other
- target, hello2, we could simply duplicate
- them. However, as projects grow, that approach leads to a great
- deal of repeated boilerplate in Jamfiles.
+ If we want the same requirements for our other target, hello2
+ , we could simply duplicate them. However, as projects grow,
+ that approach leads to a great deal of repeated boilerplate in Jamfiles.
- Fortunately, there's a better way. Each project can specify a
- set of attributes, including
- requirements:
+ Fortunately, there's a better way. Each project can specify a set of
+ attributes, including requirements:
project
@@ -211,11 +208,10 @@ project
;
exe hello : hello.cpp ;
-exe hello2 : hello.cpp ;
-
+exe hello2 : hello.cpp ;
- The effect would be as if we specified the same requirement for
- both hello and hello2.
+ The effect would be as if we specified the same requirement for both
+ hello and hello2.
@@ -223,17 +219,16 @@ exe hello2 : hello.cpp ;
Project Hierarchies
- So far we've only considered examples with one project
- —a. with one user-written Boost.Jam file,
- Jamroot). A typical large codebase would be
- composed of many projects organized into a tree. The top of the
- tree is called the project root. Every
- subproject is defined by a file called
- Jamfile in a descendant directory of the
- project root. The parent project of a subproject is defined by
- the nearest Jamfile or
- Jamroot file in an ancestor directory. For
- example, in the following directory layout:
+
+ So far we have only considered examples with one project —a. with
+ one user-written Boost.Jam file, Jamroot). A typical
+ large codebase would be composed of many projects organized into a tree.
+ The top of the tree is called the project root.
+ Every subproject is defined by a file called Jamfile
+ in a descendant directory of the project root. The parent project of a
+ subproject is defined by the nearest Jamfile or
+ Jamroot file in an ancestor directory. For example,
+ in the following directory layout:
top/
@@ -253,10 +248,9 @@ top/
. `-- bar.cpp
- the project root is top/. The projects in
- top/app/ and
- top/util/foo/ are immediate children of the
- root project.
+ the project root is top/. The projects in
+ top/app/ and top/util/foo/ are
+ immediate children of the root project.
@@ -551,7 +545,6 @@ exe app : app.cpp core ;
-