From d77573c4c97fc41a16fc60cd51995713c9b048d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jurko=20Gospodneti=C4=87?= Date: Thu, 1 May 2008 10:03:15 +0000 Subject: [PATCH] Boost Build documentation typo correction. Removed trailing spaces. Minor stylistic changes. [SVN r44971] --- v2/doc/src/tutorial.xml | 117 ++++++++++++++++++++-------------------- 1 file changed, 57 insertions(+), 60 deletions(-) diff --git a/v2/doc/src/tutorial.xml b/v2/doc/src/tutorial.xml index 4877ac671..9af1adfd7 100644 --- a/v2/doc/src/tutorial.xml +++ b/v2/doc/src/tutorial.xml @@ -18,7 +18,7 @@ This section will guide you though the most basic features of Boost.Build V2. We will start with the “Hello, world” example, - learn how to use libraries, and finish with testing and installing features. + learn how to use libraries, and finish with testing and installing features.
@@ -37,9 +37,9 @@ exe hello : hello.cpp ; things. First of all, just invoking bjam will build the hello executable by compiling and - linking hello.cpp. By default, debug variant + linking hello.cpp. By default, debug variant is built. Now, to build the - release variant of hello, invoke + release variant of hello, invoke bjam release @@ -66,7 +66,7 @@ bjam debug release Since we have already built both variants of hello, hello.cpp won't be recompiled; instead the existing object files will just be linked into the - corresponding variants of hello2. Now + corresponding variants of hello2. Now let's remove all the built products: @@ -140,7 +140,7 @@ bjam variant=release inlining=off debug-symbols=on
Build Requests and Target Requirements - + The set of properties specified on the command line constitute a build request—a description of the desired properties for building the requested targets (or, @@ -162,15 +162,15 @@ bjam variant=release inlining=off debug-symbols=on -exe hello +exe hello : hello.cpp : <include>boost <threading>multi ; - + When hello is built, the two - requirements specified above will always be present. + requirements specified above will always be present. If the build request given on the bjam command-line explictly contradicts a target's requirements, the target requirements usually override (or, in the case of @@ -187,7 +187,7 @@ See The value of the <include> feature is relative to the location of Jamroot where it's - used. + used. @@ -200,14 +200,14 @@ See target, hello2, we could simply duplicate them. However, as projects grow, that approach leads to a great deal of repeated boilerplate in Jamfiles. - + 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 +project + : requirements <include>/home/ghost/Work/boost <threading>multi ; exe hello : hello.cpp ; @@ -236,7 +236,7 @@ exe hello2 : hello.cpp ; example, in the following directory layout: -top/ +top/ | +-- Jamroot | @@ -244,7 +244,7 @@ top/ | | | +-- Jamfile | `-- app.cpp - | + | `-- util/ | +-- foo/ @@ -274,7 +274,7 @@ top/ Projects inherit all attributes (such as requirements) from their parents. Inherited requirements are combined with - any requirements specified by the subproject. + any requirements specified by the subproject. For example, if top/Jamroot has @@ -289,8 +289,8 @@ top/ rather than added-to, in subprojects. See for more information - - More details can be found in + + More details can be found in . @@ -346,7 +346,7 @@ exe app : app.cpp ../util/foo//bar ; While app.cpp refers to a regular source file, ../util/foo//bar is a reference to another target: a library bar declared in the Jamfile at - ../util/foo. + ../util/foo. @@ -378,13 +378,13 @@ bjam app optimization=full define=USE_ASM app.cpp. We could manually add the necessary #include paths to app's requirements as values of the - <include> feature, but then this work will + <include> feature, but then this work will be repeated for all programs that use foo. A better solution is to modify util/foo/Jamfile in this way: -project +project : usage-requirements <include>. ; @@ -399,7 +399,7 @@ lib foo : foo.cpp ; Another improvement is using symbolic identifiers to refer to the library, as opposed to Jamfile location. - In a large project, a library can be used by many targets, and if + In a large project, a library can be used by many targets, and if they all use Jamfile location, a change in directory organization entails much work. The solution is to use project ids—symbolic names @@ -415,14 +415,14 @@ use-project /library-example/foo : util/foo ; exe app : app.cpp /library-example/foo//bar ; -The /library-example/foo//bar syntax is used +The /library-example/foo//bar syntax is used to refer to the target bar in the project with id /library-example/foo. We've achieved our goal—if the library is moved to a different directory, only Jamroot must be modified. Note that project ids are global—two Jamfiles are not allowed to assign the same project id to different directories. - + @@ -434,12 +434,12 @@ The /library-example/foo//bar syntax is used <library>/boost/filesystem//fs to the project's requirements, like this: -project +project : requirements <source>/boost/filesystem//fs - ; + ; - +
@@ -457,38 +457,35 @@ project dynamic), which are only referred to from executables, and must be available at run time. Boost.Build can create and use both kinds. - + The kind of library produced from a lib target is determined by the value of the link feature. Default - value is shared, and to build static library, the value - should be static. You can either requiest static build + value is shared, and to build a static library, the value + should be static. You can request a static build either on the command line: bjam link=static - or in the library's requirements: + or in the library's requirements: lib l : l.cpp : <link>static ; - We can also use the <link> property - to express linking requirements on a per-target basis. - For example, if a particular executable can be correctly built - only with the static version of a library, we can qualify the - executable's target - reference to the library as follows: + We can also use the <link> property to express + linking requirements on a per-target basis. For example, if a particular + executable can be correctly built only with the static version of a + library, we can qualify the executable's target reference to the + library as follows: - @@ -521,14 +518,14 @@ alias foo : /other_project//bar/<link>static ; exe e1 : e1.cpp foo ; exe e10 : e10.cpp foo ; - The alias + The alias rule is specifically used to rename a reference to a target and possibly change the properties. - +