diff --git a/v2/doc/src/tutorial.xml b/v2/doc/src/tutorial.xml
index 91d87b4ce..141ed9196 100644
--- a/v2/doc/src/tutorial.xml
+++ b/v2/doc/src/tutorial.xml
@@ -30,7 +30,7 @@
example/hello/ directory. The project is described by
a file called Jamroot that contains:
-
+
exe hello : hello.cpp ;
@@ -49,7 +49,7 @@ b2 release
once, without any unnecessary recompilation. Let us extend the example by
adding another line to our project's Jamroot:
-
+
exe hello2 : hello.cpp ;
@@ -160,7 +160,7 @@ b2 variant=release inlining=off debug-symbols=on
illustrates how these requirements might be specified.
-
+
exe hello
: hello.cpp
: <include>boost <threading>multi
@@ -203,7 +203,7 @@ exe hello
Fortunately, there's a better way. Each project can specify a set of
attributes, including requirements:
-
+
project
: requirements <include>/home/ghost/Work/boost <threading>multi
;
@@ -272,7 +272,7 @@ top/
any requirements specified by the subproject.
For example, if top/Jamroot has
-
+
<include>/home/ghost/local
@@ -297,7 +297,7 @@ top/
Jamfile explicitly requests it. In our example,
top/Jamroot might contain:
-
+
build-project app ;
@@ -327,14 +327,14 @@ build-project app ;
use libraries from top/util/foo. If
top/util/foo/Jamfile contains
-
+
lib bar : bar.cpp ;
then to use this library in top/app/Jamfile, we can
write:
-
+
exe app : app.cpp ../util/foo//bar ;
@@ -376,7 +376,7 @@ b2 app optimization=full define=USE_ASM
repeated for all programs that use foo. A better
solution is to modify util/foo/Jamfile in this way:
-
+
project
: usage-requirements <include>.
;
@@ -398,7 +398,7 @@ lib foo : foo.cpp ;
code to Jamroot:
-
+
use-project /library-example/foo : util/foo ;
@@ -425,7 +425,7 @@ exe app : app.cpp /library-example/foo//bar ;
requirements, like this:
-
+
project
: requirements <library>/boost/filesystem//fs
;
@@ -451,7 +451,7 @@ project
command line:
b2 link=static
or in the library's requirements:
- lib l : l.cpp : <link>static ;
+ lib l : l.cpp : <link>static ;
@@ -470,7 +470,7 @@ project
VP: to be addressed when this section is moved. See comment below.
-->
-
+
exe important : main.cpp helpers/<link>static ;
No matter what arguments are specified on the b2
@@ -485,7 +485,7 @@ exe important : main.cpp helpers/<link>static ;
that library is used by many targets, you could use
target references everywhere:
-
+
exe e1 : e1.cpp /other_project//bar/<link>static ;
exe e10 : e10.cpp /other_project//bar/<link>static ;
@@ -515,7 +515,7 @@ exe e10 : e10.cpp foo ;
When one library uses another, you put the second library in the source
list of the first. For example:
-
+
lib utils : utils.cpp /boost/filesystem//fs ;
lib core : core.cpp utils ;
exe app : app.cpp core ;
@@ -554,14 +554,14 @@ exe app : app.cpp core ;
release variant is built. This can be achieved using
conditional requirements.
-
+
lib network : network.cpp
: <link>shared:<define>NEWORK_LIB_SHARED
<variant>release:<define>EXTRA_FAST
;
In the example above, whenever network is built with
- <link>shared, <define>NEWORK_LIB_SHARED
+ <link>shared, <define>NEWORK_LIB_SHARED
will be in its properties, too. Also, whenever its release variant
is built, <define>EXTRA_FAST will appear in its
properties.
@@ -573,15 +573,15 @@ lib network : network.cpp
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 : <toolset>gcc ; # alternative 2
lib demangler : demangler_msvc.cpp : <toolset>msvc ; # alternative 3
When building demangler, Boost.Build will compare
requirements for each alternative with build properties to find the best
- match. For example, when building with <toolset>gcc
+ match. For example, when building with <toolset>gcc
alternative 2, will be selected, and when building with
- <toolset>msvc alternative 3 will be selected. In all
+ <toolset>msvc alternative 3 will be selected. In all
other cases, the most generic alternative 1 will be built.
@@ -595,7 +595,7 @@ lib demangler : demangler_msvc.cpp : <toolset>msvc ; # alternative 3file property. Target alternatives can be used to
associate multiple library files with a single conceptual target. For
example:
-
+
# util/lib2/Jamfile
lib lib2
:
@@ -617,7 +617,7 @@ lib lib2
Once a prebuilt target has been declared, it can be used just like any
other target:
-
+
exe app : app.cpp ../util/lib2//lib2 ;
As with any target, the alternative selected depends on the properties
@@ -632,7 +632,7 @@ exe app : app.cpp ../util/lib2//lib2 ;
by searching through some set of predetermined paths—should be
declared almost like regular ones:
-
+
lib pythonlib : : <name>python22 ;
We again don't specify any sources, but give a name
@@ -645,12 +645,12 @@ lib pythonlib : : <name>python22 ;
We can also specify where the toolset should look for the library:
-
+
lib pythonlib : : <name>python22 <search>/opt/lib ;
And, of course, target alternatives can be used in the usual way:
-
+
lib pythonlib : : <name>python22 <variant>release ;
lib pythonlib : : <name>python22_d <variant>debug ;