2
0
mirror of https://github.com/boostorg/build.git synced 2026-02-13 00:12:11 +00:00

Replace 'bjam' with 'b2' everywhere

[SVN r75504]
This commit is contained in:
Vladimir Prus
2011-11-16 07:57:00 +00:00
parent 44293826af
commit 03e6e5dbac
6 changed files with 42 additions and 42 deletions

View File

@@ -13,7 +13,7 @@
<para>
This is not possible, since Jamfile does not have "current" value of any
feature, be it toolset, build variant or anything else. For a single
invocation of <filename>bjam</filename>, any given main target can be
run of Boost.Build, any given main target can be
built with several property sets. For example, user can request two build
variants on the command line. Or one library is built as shared when used
from one application, and as static when used from another. Each Jamfile

View File

@@ -29,7 +29,7 @@
<listitem>
<simpara>
Run
<screen>./bjam install --prefix=<replaceable>PREFIX</replaceable></screen>
<screen>./b2 install --prefix=<replaceable>PREFIX</replaceable></screen>
where <replaceable>PREFIX</replaceable> is a directory where you
want Boost.Build to be installed.
</simpara>
@@ -51,7 +51,7 @@
Now that Boost.Build is installed, you can try some of examples. Copy
<filename><replaceable>PREFIX</replaceable>/share/boost-build/examples/hello</filename>
to a different directory, then change to that directory and run:
<screen><filename><replaceable>PREFIX</replaceable>/bin/bjam</filename></screen>
<screen><filename><replaceable>PREFIX</replaceable>/bin/b2</filename></screen>
A simple executable should be built.
</para>

View File

@@ -17,12 +17,12 @@
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
<command>bjam</command> on the command line is as follows:
<command>b2</command> on the command line is as follows:
<orderedlist>
<listitem>
<para>
Boost.Jam tries to find Boost.Build and loads the top-level module.
The exact process is described in <xref linkend=
Boost.Build executable tries to find Boost.Build modules and
loads the top-level module. The exact process is described in <xref linkend=
"bbv2.reference.init"/>
</para>
</listitem>
@@ -134,7 +134,7 @@ exe a : a.cpp ;
all build files are parsed, Boost.Build considers properties requested on the
command line. Supposed you have invoked Boost.Build with:
<screen>
bjam toolset=gcc toolset=msvc
b2 toolset=gcc toolset=msvc
</screen>
In that case, the metatarget will be called twice, once with <code>toolset=gcc</code>
and once with <code>toolset=msvc</code>. Both invocations will produce concrete
@@ -325,7 +325,7 @@ rule test ( )
import <replaceable>module</replaceable> ;
import <replaceable>module</replaceable> : <replaceable>rule</replaceable> ;
</programlisting>
The first form imports the specified bjam module. All rules from that
The first form imports the specified module. All rules from that
module are made available using the qualified name: <code><replaceable>
module</replaceable>.<replaceable>rule</replaceable></code>. The second
form imports the specified rules only, and they can be called using
@@ -581,7 +581,7 @@ using gcc : 3.4 : g++-3.4 ;
<section id="bbv2.overview.invocation">
<title>Invocation</title>
<para>To invoke Boost.Build, type <command>bjam</command> on the command line. Three kinds
<para>To invoke Boost.Build, type <command>b2</command> on the command line. Three kinds
of command-line tokens are accepted, in any order:</para>
<variablelist>
<varlistentry>
@@ -615,20 +615,20 @@ using gcc : 3.4 : g++-3.4 ;
<para>To build all targets defined in Jamfile in the current directory with default properties, run:
<screen>
bjam
b2
</screen>
</para>
<para>To build specific targets, specify them on the command line:
<screen>
bjam lib1 subproject//lib2
b2 lib1 subproject//lib2
</screen>
</para>
<para>To request a certain value for some property, add <literal>
<replaceable>property</replaceable>=<replaceable>value</replaceable></literal> to the command line:
<screen>
bjam toolset=gcc variant=debug optimization=space
b2 toolset=gcc variant=debug optimization=space
</screen>
</para>
</section>
@@ -951,7 +951,7 @@ bjam toolset=gcc variant=debug optimization=space
once for each specified value of a feature. For example, if you use
</para>
<screen>
bjam link=static link=shared threading=single threading=multi
b2 link=static link=shared threading=single threading=multi
</screen>
<para>
Then a total of 4 builds will be performed. For convenience,
@@ -959,13 +959,13 @@ bjam link=static link=shared threading=single threading=multi
you can separate the values with commands, for example:
</para>
<screen>
bjam link=static,shared threading=single,multi
b2 link=static,shared threading=single,multi
</screen>
<para>
The comma has special meaning only if the feature has a fixed set of values, so
</para>
<screen>
bjam include=static,shared
b2 include=static,shared
</screen>
<para>is not treated specially.</para>
@@ -1299,7 +1299,7 @@ exe hello : hello.cpp
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
<code>bjam hello..helpers</code>.
<code>b2 hello..helpers</code>.
</para>
<para>When no target is requested on the command line, all targets in the
@@ -1541,7 +1541,7 @@ project tennis
The command line specifies which targets to build and with which
properties. For example:
<programlisting>
bjam app1 lib1//lib1 toolset=gcc variant=debug optimization=full
b2 app1 lib1//lib1 toolset=gcc variant=debug optimization=full
</programlisting>
would build two targets, "app1" and "lib1//lib1" with the specified
properties. You can refer to any targets, using
@@ -1549,7 +1549,7 @@ bjam app1 lib1//lib1 toolset=gcc variant=debug optimization=full
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:
<programlisting>
bjam app1 lib1//lib1 gcc debug optimization=full
b2 app1 lib1//lib1 gcc debug optimization=full
</programlisting>
The complete syntax, which has some additional shortcuts, is
described in <xref linkend="bbv2.overview.invocation"/>.
@@ -1640,7 +1640,7 @@ bjam app1 lib1//lib1 gcc debug optimization=full
<section><title>Building a Project</title>
<para>Often, a user builds a complete project, not just one main
target. In fact, invoking <command>bjam</command> without
target. In fact, invoking <command>b2</command> without
arguments
<!-- do you know the difference between parameters and
arguments? I only learned this year -->

View File

@@ -45,7 +45,7 @@ rule boost-build ( location ? )
boost-build build-system ;
</programlisting>
In this case, running bjam anywhere in the project tree will
In this case, running <command>b2</command> anywhere in the project tree will
automatically find the build system.</para>
<para>The default <filename>bootstrap.jam</filename>, after loading some standard
@@ -227,13 +227,13 @@ constant VERSION : 1.34.0 ;
<listitem><para>Same as <literal>constant</literal> except that
the value is treated as path relative to Jamfile location. For example,
if <command>bjam</command> is invoked in the current directory,
if <command>b2</command> is invoked in the current directory,
and Jamfile in <filename>helper</filename> subdirectory has:
<programlisting>
path-constant DATA : data/a.txt ;
</programlisting>
then the variable <varname>DATA</varname> will be set to
<literal>helper/data/a.txt</literal>, and if <command>bjam</command>
<literal>helper/data/a.txt</literal>, and if <command>b2</command>
is invoked from the <filename>helper</filename> directory, then
the variable <varname>DATA</varname> will be set to
<literal>data/a.txt</literal>.

View File

@@ -476,8 +476,8 @@ boost-test(<replaceable>test-type</replaceable>) <replaceable>path</replaceable>
</para>
<para>
It is possible to process the list of tests, the output of bjam during
command run, and the presense/absense of the <filename>*.test</filename>
It is possible to process the list of tests, Boost.Build output
and the presense/absense of the <filename>*.test</filename>
files created when test passes into human-readable status table of tests.
Such processing utilities are not included in Boost.Build.
</para>
@@ -534,7 +534,7 @@ actions in2out
in2out $(&lt;) $(&gt;)
}
</programlisting>
If you run <command>bjam</command> and <filename>file.out</filename> does
If you run <command>b2</command> and <filename>file.out</filename> does
not exist, Boost.Build will run the <command>in2out</command> command to
create that file. For more details on specifying actions, see <xref
linkend="bbv2.overview.jam_language.actions"/>.
@@ -735,7 +735,7 @@ using gcc : arm : arm-none-linux-gnueabi-g++ ;
just request that this compiler version to be used:
</para>
<screen>
bjam toolset=gcc-arm
b2 toolset=gcc-arm
</screen>
<para>
@@ -745,9 +745,9 @@ bjam toolset=gcc-arm
</para>
<screen>
# On windows box
bjam toolset=gcc-arm <emphasis role="bold">target-os=linux</emphasis>
b2 toolset=gcc-arm <emphasis role="bold">target-os=linux</emphasis>
# On Linux box
bjam toolset=gcc-mingw <emphasis role="bold">target-os=windows</emphasis>
b2 toolset=gcc-mingw <emphasis role="bold">target-os=windows</emphasis>
</screen>
<para>
For the complete list of allowed opeating system names, please see the documentation for

View File

@@ -35,13 +35,13 @@ exe hello : hello.cpp ;
</programlisting>
Even with this simple setup, you can do some interesting things. First of
all, just invoking <command>bjam</command> will build the <filename>hello
all, just invoking <command>b2</command> will build the <filename>hello
</filename> executable by compiling and linking <filename>hello.cpp
</filename>. By default, debug variant is built. Now, to build the release
variant of <filename>hello</filename>, invoke
<screen>
bjam release
b2 release
</screen>
Note that debug and release variants are created in different directories,
@@ -56,7 +56,7 @@ exe hello2 : hello.cpp ;
Now let us build both the debug and release variants of our project again:
<screen>
bjam debug release
b2 debug release
</screen>
Note that two variants of <filename>hello2</filename> are linked. Since we
@@ -66,7 +66,7 @@ bjam debug release
let us remove all the built products:
<screen>
bjam --clean debug release
b2 --clean debug release
</screen>
It is also possible to build or clean specific targets. The following two
@@ -74,8 +74,8 @@ bjam --clean debug release
<filename>hello2</filename>.
<screen>
bjam hello2
bjam --clean hello2
b2 hello2
b2 --clean hello2
</screen>
</para>
</section>
@@ -102,7 +102,7 @@ bjam --clean hello2
builds the project's <code>release</code> variant with inlining
disabled and debug symbols enabled:
<screen>
bjam release inlining=off debug-symbols=on
b2 release inlining=off debug-symbols=on
</screen>
</para>
@@ -116,12 +116,12 @@ bjam release inlining=off debug-symbols=on
<para>
The <option>release</option> and <option>debug</option> that we have seen
in <command>bjam</command> invocations are just a shorthand way to specify
in <command>b2</command> invocations are just a shorthand way to specify
values of the <varname>variant</varname> feature. For example, the
command above could also have been written this way:
<screen>
bjam variant=release inlining=off debug-symbols=on
b2 variant=release inlining=off debug-symbols=on
</screen>
</para>
@@ -170,7 +170,7 @@ exe hello
<para>
When <filename>hello</filename> is built, the two requirements specified
above will always be present. If the build request given on the
<command>bjam</command> command-line explictly contradicts a target's
<command>b2</command> command-line explictly contradicts a target's
requirements, the target requirements usually override (or, in the case
of &#x201C;free&rdquo;&#x201D; features like
<varname>&lt;include&gt;</varname>,
@@ -289,7 +289,7 @@ top/
</para>
<para>
Invoking <command>bjam</command> without explicitly specifying
Invoking <command>b2</command> without explicitly specifying
any targets on the command line builds the project rooted in the
current directory. Building a project does not automatically
cause its subprojects to be built unless the parent project's
@@ -352,7 +352,7 @@ exe app : app.cpp ../util/foo//bar ;
<para>Suppose we build <filename>app</filename> with:
<screen>
bjam app optimization=full define=USE_ASM
b2 app optimization=full define=USE_ASM
</screen>
Which properties will be used to build <code>foo</code>? The answer is
that some features are
@@ -448,7 +448,7 @@ project
<literal>shared</literal>, and to build a static library, the value should
be <literal>static</literal>. You can request a static build either on the
command line:
<programlisting>bjam link=static</programlisting>
<programlisting>b2 link=static</programlisting>
or in the library's requirements:
<programlisting>lib l : l.cpp : &lt;link&gt;static ;</programlisting>
</para>
@@ -472,7 +472,7 @@ project
<programlisting>
exe important : main.cpp helpers/&lt;link&gt;static ;</programlisting>
No matter what arguments are specified on the <command>bjam</command>
No matter what arguments are specified on the <command>b2</command>
command line, <filename>important</filename> will only be linked with the
static version of <filename>helpers</filename>.
</para>