diff --git a/v2/doc/development_plan.html b/v2/doc/development_plan.html index a64365740..b18aa1e95 100644 --- a/v2/doc/development_plan.html +++ b/v2/doc/development_plan.html @@ -91,7 +91,7 @@ Alpha (TBD)

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.