Optimization. Using buildable tools: consider using bison, which
- is itself build with Boost.Build.
+ is itself built with Boost.Build.
diff --git a/v2/doc/src/advanced.xml b/v2/doc/src/advanced.xml
index 68094c00e..9fd2e7ae2 100644
--- a/v2/doc/src/advanced.xml
+++ b/v2/doc/src/advanced.xml
@@ -36,7 +36,7 @@
Finally, using build request specified on the command line,
Boost.Build decides which targets should be built, and how. That
- information is passes back to Boost.Jam, which takes care of
+ information is passed back to Boost.Jam, which takes care of
actually running commands.
@@ -115,13 +115,13 @@ 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 path
- will be used, and there's ne need to explicitly specify the command.
+ will be used, and there's no need to explicitly specify the command.
As shown above, both "version" and "invocation command" parameters
- are optional, but there's important restriction: if you configure the same
- compiler more then once, you must pass the "version" parameter every
- time. For example, the following is not allowed:
+ are optional, but there's an important restriction: if you configure the
+ same compiler more then once, you must pass the "version" parameter
+ every time. For example, the following is not allowed:
using gcc ;
using gcc : 3.4 : g++-3.4 ;
@@ -177,7 +177,7 @@ using gcc : 3.4 : : <compileflags>-m64 <linkflags>-m64 ;
In addition to Jamfiles, Boost.Build has another user-editable
file, project-root.jam, which is mostly usefull to declare constants
- global to all the projects. It is also describe below.
@@ -350,7 +350,7 @@ function-name main-target-name
"usage-requirements" is the list of properties that will be
propagated to all main targets that use this one, i.e. to all
- dependedents.
+ dependents.
@@ -410,12 +410,12 @@ exe c : c.cpp /boost/program_options//program_opions ;
tutorial.
- Sometimes a main target is really needed only by some other
- main target. E.g. a rule that declares test-suite uses a main
- target that represent test, but those main targets are rarely
- needed by themself.
+ Sometimes a main target is really needed only by some other main
+ target. For example, a rule that declares a test-suite uses a main
+ target that represent test, but those main targets are rarely needed
+ by themself.
- It possible to declare target inline, i.e. the "sources"
+ It is possible to declare target inline, i.e. the "sources"
parameter may include call to other main rules. For example:
@@ -450,7 +450,7 @@ project id : <attributes> ;
Here, attributes is a sequence of (attribute-name,
attribute-value) pairs. The list of attribute names along with its
- handling is also shown in the table below. For example, it it
+ handling is also shown in the table below. For example, it is
possible to write:
project tennis
@@ -660,7 +660,7 @@ project tennis
project-root can be merged together. To achieve this effect, the
project root file should call the project rule. The
semantic is precisely the same as if the call was made in
- Jamfile, except that project-root.jam will start serve as
+ Jamfile, except that project-root.jam will start to serve as
Jamfile. The Jamfile in the directory of project-root.jam will be
ignored, and project-root.jam will be able to declare main
targets as usual.
@@ -725,7 +725,7 @@ should be absolute project id.
- The command line specifies which targets to built and which what
+ The command line specifies which targets to build and with what
properties. For example:
bjam app1 lib1//lib1 toolset=gcc variant=debug optimization=full
@@ -738,7 +738,7 @@ bjam app1 lib1//lib1 toolset=gcc variant=debug optimization=full
bjam app1 lib1//lib1 gcc debug optimization=full
- The complete syntax which had some additional shortcuts if described here.
@@ -838,7 +838,7 @@ lib b : : <variant>debug <file>/pool/debug/b.so ;
For convenience, the following syntax is allowed:
lib z ;
-lib giu db aux ;
+lib gui db aux ;
and is does exactly the same as:
@@ -865,7 +865,7 @@ lib png : z : <name>png ;
library, (say, b) is linked dynamically, the b
library will be incorporated in a. (If b
is dynamic library as well, then a will only refer to
- it, and don't include any extra code.) When the a
+ it, and not include any extra code.) When the a
library is linked statically, Boost.Build will assure that all
executables which link to a will also link to
b.
@@ -1048,7 +1048,7 @@ unit-test helpers_test : helpers_test.cpp helpers ;
Rationale: Runtime debugging is on in debug build
- so suit expectations of people used various IDEs. It's
+ to suit expectations of people used various IDEs. It's
assumed other folks don't have any specific expectation in
this point.
diff --git a/v2/doc/src/reference.xml b/v2/doc/src/reference.xml
index b9e0fa210..38a6e7dbb 100644
--- a/v2/doc/src/reference.xml
+++ b/v2/doc/src/reference.xml
@@ -46,7 +46,7 @@
<toolset>gcc-3.0.1.
A property set is a set of properties (i.e. a
- collection without dublicates), for instance:
+ collection without duplicates), for instance:
<toolset>gcc <runtime-link>static.A property path is a property set whose elements have
@@ -525,7 +525,7 @@ part should have the either the form
feature-name=feature-value1[","feature-valueN]*
-or, in case of implict feature
+or, in case of implicit feature
feature-value1[","feature-valueN;]*
@@ -611,7 +611,7 @@ linked binaries would be created.
--no-error-backtrace
- Don't print backtrace on errors. Primary usefull for
+ Don't print backtrace on errors. Primary useful for
testing.
diff --git a/v2/doc/src/tutorial.xml b/v2/doc/src/tutorial.xml
index a68dce914..3cf155265 100644
--- a/v2/doc/src/tutorial.xml
+++ b/v2/doc/src/tutorial.xml
@@ -235,7 +235,7 @@ top/
the project root is top/. Because there is
no Jamfile in
- top/lib/, the projects in
+ top/util/, the projects in
top/src/ and
top/util/foo/ are immediate children of the
root project.
@@ -550,7 +550,7 @@ exe e10 : e10.cpp foo ;
The first mechanism is called conditinal
requirement. For example, you might want to set specific
defines when the library is build as shared, or you have your own define
- to be used in relese mode. Here's a piece of Jamfile.
+ to be used in release mode. Here's a piece of Jamfile.
lib network : network.cpp
: <link>shared:<define>NEWORK_LIB_SHARED
@@ -565,7 +565,7 @@ lib network : network.cpp
Sometimes different variant of a target are so different, that
describing them using conditional requirements would be hard. Imagine
- that a library has different sources on two two supported toolsets, and
+ that a library has different sources on two supported toolsets, and
dummy implementation for all the other toolset. We can express this
situation using target alternatives:
@@ -609,7 +609,7 @@ lib lib2
If "app" binary should use "lib2", we can write:
-exe app : app.cpp /util/foo//lib2 ../util/lib2//lib2 ;
+exe app : app.cpp ../util/lib2//lib2 ;
If we build release version of "app", then it will be linked
@@ -643,7 +643,7 @@ lib zlib : : <name>z_d <variant>debug ;
version of zlib, but for other libraries this is quite reasonable.
- More advanced use of prebuilt target is descibed in More advanced use of prebuilt target is described in recipes.