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:
@@ -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
|
||||
|
||||
@@ -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>
|
||||
|
||||
|
||||
@@ -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 -->
|
||||
|
||||
@@ -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>.
|
||||
|
||||
@@ -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 $(<) $(>)
|
||||
}
|
||||
</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
|
||||
|
||||
@@ -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 “free”” features like
|
||||
<varname><include></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 : <link>static ;</programlisting>
|
||||
</para>
|
||||
@@ -472,7 +472,7 @@ project
|
||||
<programlisting>
|
||||
exe important : main.cpp helpers/<link>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>
|
||||
|
||||
Reference in New Issue
Block a user