From d37ebb3a3078d0a65075103157cffb7cd26834e5 Mon Sep 17 00:00:00 2001 From: Steven Watanabe Date: Wed, 4 Apr 2012 18:52:51 +0000 Subject: [PATCH] Syntax highlighting in the tutorial. [SVN r77763] --- v2/doc/src/tutorial.xml | 50 ++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/v2/doc/src/tutorial.xml b/v2/doc/src/tutorial.xml index 91d87b4ce..141ed9196 100644 --- a/v2/doc/src/tutorial.xml +++ b/v2/doc/src/tutorial.xml @@ -30,7 +30,7 @@ example/hello/ directory. The project is described by a file called Jamroot that contains: - + exe hello : hello.cpp ; @@ -49,7 +49,7 @@ b2 release once, without any unnecessary recompilation. Let us extend the example by adding another line to our project's Jamroot: - + exe hello2 : hello.cpp ; @@ -160,7 +160,7 @@ b2 variant=release inlining=off debug-symbols=on illustrates how these requirements might be specified. - + exe hello : hello.cpp : <include>boost <threading>multi @@ -203,7 +203,7 @@ exe hello 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 ; @@ -272,7 +272,7 @@ top/ any requirements specified by the subproject. For example, if top/Jamroot has - + <include>/home/ghost/local @@ -297,7 +297,7 @@ top/ Jamfile explicitly requests it. In our example, top/Jamroot might contain: - + build-project app ; @@ -327,14 +327,14 @@ build-project app ; use libraries from top/util/foo. If top/util/foo/Jamfile contains - + lib bar : bar.cpp ; then to use this library in top/app/Jamfile, we can write: - + exe app : app.cpp ../util/foo//bar ; @@ -376,7 +376,7 @@ b2 app optimization=full define=USE_ASM repeated for all programs that use foo. A better solution is to modify util/foo/Jamfile in this way: - + project : usage-requirements <include>. ; @@ -398,7 +398,7 @@ lib foo : foo.cpp ; code to Jamroot: - + use-project /library-example/foo : util/foo ; @@ -425,7 +425,7 @@ exe app : app.cpp /library-example/foo//bar ; requirements, like this: - + project : requirements <library>/boost/filesystem//fs ; @@ -451,7 +451,7 @@ project command line: b2 link=static or in the library's requirements: - lib l : l.cpp : <link>static ; + lib l : l.cpp : <link>static ; @@ -470,7 +470,7 @@ project VP: to be addressed when this section is moved. See comment below. --> - + exe important : main.cpp helpers/<link>static ; No matter what arguments are specified on the b2 @@ -485,7 +485,7 @@ exe important : main.cpp helpers/<link>static ; that library is used by many targets, you could use target references everywhere: - + exe e1 : e1.cpp /other_project//bar/<link>static ; exe e10 : e10.cpp /other_project//bar/<link>static ; @@ -515,7 +515,7 @@ exe e10 : e10.cpp foo ; When one library uses another, you put the second library in the source list of the first. For example: - + lib utils : utils.cpp /boost/filesystem//fs ; lib core : core.cpp utils ; exe app : app.cpp core ; @@ -554,14 +554,14 @@ exe app : app.cpp core ; release variant is built. This can be achieved using conditional requirements. - + lib network : network.cpp : <link>shared:<define>NEWORK_LIB_SHARED <variant>release:<define>EXTRA_FAST ; In the example above, whenever network is built with - <link>shared, <define>NEWORK_LIB_SHARED + <link>shared, <define>NEWORK_LIB_SHARED will be in its properties, too. Also, whenever its release variant is built, <define>EXTRA_FAST will appear in its properties. @@ -573,15 +573,15 @@ lib network : network.cpp library actually uses different source files depending on the toolset used to build it. We can express this situation using target alternatives: - + lib demangler : dummy_demangler.cpp ; # alternative 1 lib demangler : demangler_gcc.cpp : <toolset>gcc ; # alternative 2 lib demangler : demangler_msvc.cpp : <toolset>msvc ; # alternative 3 When building demangler, Boost.Build will compare requirements for each alternative with build properties to find the best - match. For example, when building with <toolset>gcc + match. For example, when building with <toolset>gcc alternative 2, will be selected, and when building with - <toolset>msvc alternative 3 will be selected. In all + <toolset>msvc alternative 3 will be selected. In all other cases, the most generic alternative 1 will be built. @@ -595,7 +595,7 @@ lib demangler : demangler_msvc.cpp : <toolset>msvc ; # alternative 3file property. Target alternatives can be used to associate multiple library files with a single conceptual target. For example: - + # util/lib2/Jamfile lib lib2 : @@ -617,7 +617,7 @@ lib lib2 Once a prebuilt target has been declared, it can be used just like any other target: - + exe app : app.cpp ../util/lib2//lib2 ; As with any target, the alternative selected depends on the properties @@ -632,7 +632,7 @@ exe app : app.cpp ../util/lib2//lib2 ; by searching through some set of predetermined paths—should be declared almost like regular ones: - + lib pythonlib : : <name>python22 ; We again don't specify any sources, but give a name @@ -645,12 +645,12 @@ lib pythonlib : : <name>python22 ; We can also specify where the toolset should look for the library: - + lib pythonlib : : <name>python22 <search>/opt/lib ; And, of course, target alternatives can be used in the usual way: - + lib pythonlib : : <name>python22 <variant>release ; lib pythonlib : : <name>python22_d <variant>debug ;