diff options
Diffstat (limited to 'tools/build/tutorial.html')
| -rw-r--r-- | tools/build/tutorial.html | 1522 |
1 files changed, 1522 insertions, 0 deletions
diff --git a/tools/build/tutorial.html b/tools/build/tutorial.html new file mode 100644 index 000000000..c500d2085 --- /dev/null +++ b/tools/build/tutorial.html @@ -0,0 +1,1522 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> + +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> + + <title>Boost.Build tutorial</title> + + <link href="website/bootstrap/css/bootstrap.min.css" rel="stylesheet"> + <link href="website/index.css" rel="stylesheet"> + +</head> + +<body> + + <div lang="en" class="container"> + + <div class="header"> + <ul> + <li><a href="index.html">About</a> + <li><a href="doc/html/index.html">Documentation</a> + <li><a href="http://github.com/boostorg/build">GitHub</a> + </ul> + <span><b>Boost.Build Tutorial</b></span> + </div> + + <hr class="hrhead"> + <p>Written by Boris Schäling.</p> + + <div class="toc"> + <h3>Table of Contents</h3> + + <ul> + <li><a href="#introduction">1. Introduction</a></li> + + <li><a href="#buildprocess">2. Build process</a></li> + + <li><a href="#basic_tasks">3. Basic tasks</a></li> + + <li><a href="#project_management">4. Project management</a></li> + + <li><a href="#best_practices">5. Best practices</a></li> + + <li><a href="#rule_reference">6. Rule reference</a></li> + + <li><a href="#feature_reference">7. Feature reference</a></li> + </ul> + </div> + + + <hr> + + <h2 id="introduction">Introduction<br><small>Compiler- and + platform-independent build system</small></h2> + + <div> + + <p>Boost.Build is a high-level build system which makes it as easy as + possible to manage C++ projects. The idea is to specify in + configuration files just as much as necessary to build a program. For + example it is not required to tell Boost.Build how to use a certain + compiler. Boost.Build supports many compilers out of the box and knows + how to use them. If you create a configuration file you just need to + tell Boost.Build where to find the source files, what the executable + should be called and which compiler Boost.Build should use. Boost.Build + will then try to find the compiler and automatically build the + program.</p> + + <p>As Boost.Build supports many compilers configuration files never + contain any compiler-specific options. Configuration files are entirely + compiler-independent. Of course it is possible to set options like + whether code should be optimized. However these options are written in + a language only understood by Boost.Build. Once a compiler is picked to + build a program Boost.Build translates options in configuration files + to command line options expected by the selected compiler. This makes + it possible to write configuration files once and build a program on + different platforms with different compilers.</p> + + <p>As nice as it sounds Boost.Build can only be used for C++ and C + projects. Boost.Build doesn't know how to use other compilers like a + Java compiler. Although Boost.Build is extensible it makes more sense + to use a different build system for programs implemented in other + programming languages.</p> + + <p>Boost.Build was created to build and install the <a class="link" + href="http://www.boost.org/" target="_top">Boost C++ libraries</a> + easily with different compilers on different platforms. Although + Boost.Build is part of and shipped with the Boost C++ libraries it can + be used separately for any C++ or C project. It's even possible to + <a class="link" href="http://sourceforge.net/projects/boost/files/" + target="_top">download only Boost.Build</a> in case you don't want to + use the Boost C++ libraries.</p> + + <p>This article is an introduction to help you using Boost.Build for + your own C++ or C projects. It gives you a basic understanding of how + Boost.Build works and how you start using it. After reading the article + you should not only be able to use Boost.Build for your own projects, + it will also be easier to understand the <a class="link" href= + "http://www.boost.org/doc/tools/build/doc/html/index.html" target= + "_top">Boost.Build documentation</a> as you'll know the big + picture.</p> + </div> + <hr> + + <h2 id="buildprocess">Build process<br> + <small>Jamfiles and an interpreter called b2</small> + </h2> + + <div> + + <p>The program you use to build a project managed by Boost.Build is + called <span class="command"><strong>b2</strong></span>. If you + downloaded and built the Boost C++ libraries you have used <span class= + "command"><strong>b2</strong></span> already. <span class= + "command"><strong>b2</strong></span> looks for configuration files, + reads them and builds a project accordingly. It also accepts various + command line options which can be useful for example to show all + commands executed by <span class="command"><strong>b2</strong></span> + to build a project.</p> + + <p>Projects can be large and can consist of many components whose + source code is distributed over many directories. Instead of creating + one big configuration file for the entire project components typically + get their own configuration files. This is no different with + Boost.Build: In a large project there will be many configuration files + which have to be found and interpreted by <span class= + "command"><strong>b2</strong></span>.</p> + + <p>For Boost.Build every directory with a configuration file is a + project: If there is a configuration file in a directory something can + be built. Whether it's a component in a subdirectory or a software + consisting of many components doesn't make a difference for + Boost.Build.</p> + + <p>When <span class="command"><strong>b2</strong></span> is started + it doesn't run a search for configuration files on the entire file + system. It searches for a configuration file in the current working + directory only. If it doesn't find a configuration file it doesn't do + anything. <span class="command"><strong>b2</strong></span> does not + search for configuration files in any other directory if there is no + configuration file in the current working directory.</p> + + <p>The configuration file <span class= + "command"><strong>b2</strong></span> is looking for is called + <code class="filename">Jamfile.jam</code>. Files with the extension + <code class="filename">jam</code> are called Jamfiles. If <span class= + "command"><strong>b2</strong></span> finds a Jamfile in the current + working directory it searches for more Jamfiles in parent directories. + <span class="command"><strong>b2</strong></span> climbs up parent + directories until it finds a configuration file called <code class= + "filename">Jamroot.jam</code>. <code class= + "filename">Jamroot.jam</code> is no different from <code class= + "filename">Jamfile.jam</code>. It only indicates that <span class= + "command"><strong>b2</strong></span> doesn't need to look + further.</p> + + <p>The reason why <span class="command"><strong>b2</strong></span> + looks for Jamfiles in parent directories is that it makes it possible + to group settings. If there are some components which should be built + with similar settings they can be stored in a Jamfile in a parent + directory which will be automatically used if a component in a + subdirectory is built.</p> + + <p>Please note that <span class="command"><strong>b2</strong></span> + must find a file called <code class="filename">Jamroot.jam</code>. It + is an error if no <code class="filename">Jamroot.jam</code> exists. If + <code class="filename">Jamroot.jam</code> is in the current working + directory no other file <code class="filename">Jamfile.jam</code> is + required. If <code class="filename">Jamroot.jam</code> is in a parent + directory a file <code class="filename">Jamfile.jam</code> must exist + in the current working directory - otherwise <span class= + "command"><strong>b2</strong></span> doesn't do anything.</p> + + <p>If you copy <span class="command"><strong>b2</strong></span> to a + directory which contains no Jamfiles and start the program you get an + error message. However <span class= + "command"><strong>b2</strong></span> doesn't complain that it can't + find a Jamfile. It complains about not finding the build system.</p> + <pre class="screen"> +Unable to load Boost.Build: could not find "boost-build.jam" +--------------------------------------------------------------- +Attempted search from C:\Users\Boris\Desktop up to the root + +Please consult the documentation at 'http://www.boost.org'. +</pre> + + <p>The first thing <span class="command"><strong>b2</strong></span> + does is not looking for a Jamfile but loading the build system. But + what exactly is the build system?</p> + + <p><span class="command"><strong>b2</strong></span> is an + interpreter. It doesn't really know how to build anything. What + <span class="command"><strong>b2</strong></span> does is interpreting + Jamfiles. Boost.Build is really implemented in Jamfiles. And they + contain all the logic which makes Boost.Build such a powerful tool. As + <span class="command"><strong>b2</strong></span> only does what it + reads in Jamfiles it needs to know where to find the Jamfiles + Boost.Build is made of.</p> + + <p>When <span class="command"><strong>b2</strong></span> is started + it looks for a file <code class="filename">boost-build.jam</code> in + the current working directory. If it doesn't find the file it searches + all parent directories. This file needs to contain only one line to + tell <span class="command"><strong>b2</strong></span> where to find + the build system.</p> + <pre class="programlisting"> +boost-build C:/boost_1_57_0/tools/build/src ; +</pre> + + <p>The path after <code class="code">boost-build</code> must refer to a + directory which contains a file called <code class= + "filename">bootstrap.jam</code>. This is the file <span class= + "command"><strong>b2</strong></span> needs to load the build system. + As the Boost C++ libraries ship Boost.Build you can refer to the + subdirectory <code class="filename">tools/build</code> of the root + directory of the Boost C++ libraries. And you can always use a slash as + a path separator - even if you are on Windows.</p> + + <p>Please note that there must be a space between the path and the + semicolon at the end of the line. It is an error if the space is + missing. You'll learn more about the syntax used in Jamfiles later in + this article.</p> + + <p>If <span class="command"><strong>b2</strong></span> finds + <code class="filename">boost-build.jam</code> it uses the path within + the file to load the build system. When the build system is loaded it + also prepares itself to use a certain compiler, linker and maybe other + tools required to build a project. Boost.Build refers to these programs + as a toolset. If no command line option is used to start <span class= + "command"><strong>b2</strong></span> the build system tries to find a + toolset it can use automatically. On Windows for example it searches + for Visual C++. And if it detects that Visual C++ is installed it uses + the toolset msvc.</p> + <pre class="screen"> +warning: No toolsets are configured. +warning: Configuring default toolset "msvc". +warning: If the default is wrong, your build may not work correctly. +warning: Use the "toolset=xxxxx" option to override our guess. +warning: For more configuration options, please consult +warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html +</pre> + + <p>If you start <span class="command"><strong>b2</strong></span> + without specifying which toolset should be used you see a warning. + <span class="command"><strong>b2</strong></span> tells you which + toolset it detected and decided to use. If you want to suppress the + warning you must specify the toolset yourself. For example you tell the + build system to use Visual C++ with <span class="command"><strong>b2 + toolset=msvc</strong></span>. If you want GCC to be used you enter + <span class="command"><strong>b2 toolset=gcc</strong></span>.</p> + + <p>As of today there are more than 10 toolsets supported. There is a + good chance that Boost.Build will work with the compiler you use out of + the box.</p> + + <p>Once the build system has been found, loaded and knows which toolset + to use - either because you specified one or the build system detected + one automatically - <span class="command"><strong>b2</strong></span> + looks for a file <code class="filename">Jamfile.jam</code> in the + current working directory. If it doesn't find a Jamfile an error + message is printed.</p> + <pre class="screen"> +error: error: no Jamfile in current directory found, and no target references specified. +</pre> + + <p>If you create an empty file <code class= + "filename">Jamfile.jam</code> and start <span class= + "command"><strong>b2</strong></span> again another error message is + printed.</p> + <pre class="screen"> +error: Could not find parent for project at '.' +error: Did not find Jamfile.jam or Jamroot.jam in any parent directory. +</pre> + + <p><span class="command"><strong>b2</strong></span> is ultimately + looking for a Jamfile called <code class="filename">Jamroot.jam</code>. + If it doesn't exist in the current working directory <span class= + "command"><strong>b2</strong></span> expects to find it in a parent + directory.</p> + + <p>If you create an empty file <code class= + "filename">Jamroot.jam</code> and start <span class= + "command"><strong>b2</strong></span> the error message is gone. + Obviously there is nothing done by Boost.Build. But now you know how + <span class="command"><strong>b2</strong></span> proceeds to build a + program and what the minimum Boost.Build configuration looks like.</p> + + <p>Please note that if you work on a small project and you need only + one configuration file you can simply call it <code class= + "filename">Jamroot.jam</code>. You don't need another file called + <code class="filename">Jamfile.jam</code>.</p> + </div> + <hr> + + <h2 id="basic_tasks">Basic tasks<br> + <small>Rules and features</small> + </h2> + + <div class="sect1"> + + <p>If you look at Jamfiles the syntax might remind you of configuration + files used by other build systems. Simple Jamfiles can look like plain + old configuration files where for example values seem to be assigned to + keys. What is important to understand though is that Jamfiles are + really script files. There is a programming language used to write + Jamfiles. <span class="command"><strong>b2</strong></span> isn't the + core component of Boost.Build which knows how to build programs. The + logic of Boost.Build is in the Jamfiles which tell <span class= + "command"><strong>b2</strong></span> how to build programs.</p> + + <p>Even though Boost.Build is based on a programming language you don't + need to think of programming when you create Jamfiles. The syntax of + the programming language used by Boost.Build tries to remind you more + of creating plain old configuration files. The idea is to have the best + of two worlds: A powerful and flexible programming language but a + simple syntax you might be familiar with from other build systems.</p> + + <p>This article doesn't introduce you into the programming language + Boost.Build is based on. The programming language is proprietary and + not really a joy to use. It is no competitor to popular scripting + languages like Javascript or Python. The developers of Boost.Build + recognize it and work on another version of Boost.Build based on + Python. However all of this shouldn't matter to developers who plan to + manage their projects with Boost.Build. It helps to understand the + syntax of Jamfiles better once one realizes that there is a programming + language inside Boost.Build. But it's not required to learn the details + of the programming language.</p> + + <p>Let's look at a simple Jamfile which can be used to build an + executable <span class="command"><strong>hello</strong></span> from a + source file <code class="filename">hello.cpp</code>.</p> + <pre class="programlisting"> +exe hello : hello.cpp ; +</pre> + + <p>Boost.Build provides a lot of built-in rules and <code class= + "code">exe</code> is one of them. While the documentation of + Boost.Build refers to <code class="code">exe</code> as a rule you know + already that the above Jamfile is actually built using a programming + language. As it turns out rules are simply functions. And the Jamfile + above contains a function call.</p> + + <p>For the majority of tasks which are typically required to build + programs Boost.Build provides predefined rules - or functions if you + like. As with functions in other programming languages it is possible + to pass parameters. In the Jamfile above the function <code class= + "code">exe</code> is called with the two parameters hello and + hello.cpp.</p> + + <p>The programming language Boost.Build is based on knows only one data + type: Everything is a list of strings. A list can be empty or contain + one or more strings. In the Jamfile above the function <code class= + "code">exe</code> is called with two parameters each one a list + containing one string.</p> + <pre class="programlisting"> +exe "hello" : "hello.cpp" ; +</pre> + + <p>It is possible to use quotes. It's not necessary though as after all + every item in a list has the data type string anyway. Quotes are only + used if parameters contain spaces.</p> + + <p>While there is no special delimiter between a rule and the first + parameter a colon must be used to separate other parameters. It is also + required to end a line with a semicolon just as you are used to from + C++.</p> + + <p>Please note that the programming language of Boost.Build requires + that there is a space around all tokens. For example there must be a + space on the left and on the right of the colon and there must be a + space on the left of the semicolon. Without spaces around tokens + <span class="command"><strong>b2</strong></span> won't be able to + parse Jamfiles correctly.</p> + + <p>If <span class="command"><strong>b2</strong></span> is run in a + directory which contains the Jamfile above and a source file + <code class="filename">hello.cpp</code>, and if the msvc toolset is + used on Windows a subdirectory <code class= + "filename">bin\msvc-9.0\debug</code> is created to build an executable + <code class="filename">hello.exe</code>.</p> + <pre class="screen"> +...found 9 targets... +...updating 5 targets... +common.mkdir bin +common.mkdir bin\msvc-9.0 +common.mkdir bin\msvc-9.0\debug +compile-c-c++ bin\msvc-9.0\debug\hello.obj +hello.cpp +msvc.link bin\msvc-9.0\debug\hello.exe +msvc.manifest bin\msvc-9.0\debug\hello.exe +...updated 5 targets... +</pre> + + <p>As you see it takes only one line in a Jamfile to build an + executable from a source file. And if the program is built on Windows + there is even the correct file extension <code class= + "filename">exe</code> appended.</p> + + <p>The main advantage of Boost.Build is that you specify just as much + as necessary for a build system to know how to build a program. + Anything Boost.Build can do automatically is done automatically. You + don't need to detect the platform a program is built on to decide if a + file extension like <code class="filename">exe</code> should be + appended or not. And you don't need to specify how a compiler like + Visual C++ has actually to be invoked to compile source code.</p> + + <p>Boost.Build supports a lot of toolsets out of the box. As a program + can be built using different toolsets Boost.Build uses toolset-specific + directories. This way it is possible to build a program with different + toolsets without a toolset constantly overwriting files produced by + another toolset.</p> + + <p>There are not only toolset-specific directories but also + variant-specific directories. A variant is a debug or release version + of a program. For each variant another directory is used to build a + program - again for the reason not to overwrite files produced by + another variant. By default the debug variant is used. That's why the + subdirectory <code class="filename">bin\msvc-9.0\debug</code> was + created. If you want a release version to be created you can specify + the variant on the command line with <span class="command"><strong>b2 + variant=release</strong></span> or, even simpler, <span class="command"> + <strong>b2 release </strong></span>.</p> + <pre class="screen"> +...found 9 targets... +...updating 5 targets... +common.mkdir bin +common.mkdir bin\msvc-9.0 +common.mkdir bin\msvc-9.0\release +compile-c-c++ bin\msvc-9.0\release\hello.obj +hello.cpp +msvc.link bin\msvc-9.0\release\hello.exe +msvc.manifest bin\msvc-9.0\release\hello.exe +...updated 5 targets... +</pre> + + <p>With the variant set to release the subdirectory <code class= + "filename">bin\msvc-9.0\release</code> is used to create the executable + <code class="filename">hello.exe</code>.</p> + + <p>Choosing a variant is something which is done so often that it's + sufficient to enter <span class="command"><strong>b2 + release</strong></span>. Boost.Build figures out that release is meant + to choose the variant.</p> + + <p>If you don't want to specify the variant on the command line but + want to build release versions of <code class= + "filename">hello.exe</code> by default the Jamfile has to be + changed.</p> + <pre class="programlisting"> +exe hello : hello.cpp : <variant>release ; +</pre> + + <p>The <code class="code">exe</code> rule (or, if you prefer, function) + accepts a few more parameters which are optional. The third parameter + is a list of requirements. You can think of command line options which + are always set and passed to commands run to build an executable.</p> + + <p>In order to force a release version to be built the variant has to + be set to release just as it was done before on the command line. The + syntax to set the variant in a Jamfile is different though.</p> + + <p>Boost.Build defines features which look like XML tags. One of the + features supported by Boost.Build is <code class= + "code"><variant></code>. If a feature should be set to a value it + has to be put next to it - without a space in between. Some features + are free which means they can be set to any value you want. + <code class="code"><variant></code> is a non-free feature as it + can only be set to debug or release. No other value is allowed. If + another value is set <code class="code">b2</code> will report an + error.</p> + + <p>If you run <code class="code">b2 variant=debug</code> and try to + build a debug version of <code class="filename">hello.exe</code> it + won't work as the Jamfile contains the requirement that <code class= + "filename">hello.exe</code> is built as a release version. If you want + to be able to overwrite the feature on the command line you have to + pass the feature as the fourth parameter instead of the third.</p> + <pre class="programlisting"> +exe hello : hello.cpp : : <variant>release ; +</pre> + + <p>The fourth parameter contains features which are used by default but + which can be overwritten.</p> + + <p>If you want both a debug and a release version of <code class= + "filename">hello.exe</code> to be built by default the <code class= + "code"><variant></code> feature needs to be set twice to debug + and release.</p> + <pre class="programlisting"> +exe hello : hello.cpp : : <variant>debug <variant>release ; +</pre> + + <p>It is important that <code class="code"><variant></code> is + set twice in the fourth parameter where default values are specified. + If it was the third parameter where requirements are specified + <span class="command"><strong>b2</strong></span> would report an + error. It is possible to set a feature multiple times in the + requirements but only if values are not mutually exclusive. As a + program can't be a debug and a release version at the same time + <code class="code"><variant></code> must be set in the default + values. Only then Boost.Build understands that two versions of + <code class="filename">hello.exe</code> should be built.</p> + <pre class="programlisting"> +exe hello : hello.cpp : <define>WIN32 <define>_WIN32 : <variant>debug <variant>release ; +</pre> + + <p>The above Jamfile is an example for setting a feature multiple times + in the requirements. The feature <code class= + "code"><define></code> is used to define preprocessor directives. + It is no problem to define several preprocessor directives. Thus there + are now two versions of <code class="filename">hello.exe</code> built + both with the two directives <code class="code">WIN32</code> and + <code class="code">_WIN32</code> defined.</p> + <pre class="programlisting"> +exe hello : hello.cpp : : <variant>debug <variant>release <define>WIN32 <define>_WIN32 ; +</pre> + + <p>If the definitions are moved to the fourth parameter and you run + <span class="command"><strong>b2</strong></span> you get the same two + versions of <code class="filename">hello.exe</code> built with the two + directives <code class="code">WIN32</code> and <code class= + "code">_WIN32</code>. As <code class="code"><define></code> does + not expect mutually exclusive values there is no other set of + executables generated. The only difference between this Jamfile and the + previous one is that directives passed in the fourth parameter are + default values which can be dropped while anything passed as a third + parameter is an immutable requirement.</p> + + <p>Here is another example of a feature whose values are mutually + exclusive.</p> + <pre class="programlisting"> +exe hello : hello.cpp : : <variant>debug <variant>release <optimization>speed <optimization>off ; +</pre> + + <p><span class="command"><strong>b2</strong></span> creates four + versions of <code class="filename">hello.exe</code>: A debug version + optimized for speed, a debug version with no optimization, a release + version optimized for speed and a release version with no optimization. + All of these versions are built in seperate directories which are + automatically created.</p> + + <p>So far the only rule used was <code class="code">exe</code>. But of + course Boost.Build provides many more built-in rules. Another important + rule is <code class="code">lib</code>. It is used to build a + library.</p> + <pre class="programlisting"> +lib world : world.cpp ; +</pre> + + <p>The above Jamfile builds a shared library from the source file + <code class="filename">world.cpp</code>. On Windows a file <code class= + "filename">world.dll</code> is created. The usual file extension is + again automatically appended by Boost.Build.</p> + + <p>By default a shared library is built. If you want a static library + to be generated you set the <code class="code"><link></code> + feature to static.</p> + <pre class="programlisting"> +lib world : world.cpp : <link>static ; +</pre> + + <p>Another useful rule is <code class="code">install</code>. After + executables and libraries have been built this rule can be used to + install them.</p> + <pre class="programlisting"> +exe hello : hello.cpp ; +install "C:/Program Files/hello" : hello ; +</pre> + + <p>The above Jamfile installs the executable <code class= + "filename">hello.exe</code> to the directory <code class= + "filename">C:\Program Files\hello</code>. The second parameter hello is + a reference to the target hello defined in the first line. Please note + that the path has to be put in quotes as it contains a space.</p> + + <p>Here concepts known from other build systems shine through: Instead + of thinking of function calls every line defines a target. Dependencies + are created by referencing other targets. That's how Boost.Build knows + in what order it should build targets.</p> + + <p>Typically the rule <code class="code">install</code> is written + differently though. Instead of passing the installation directory as + the first parameter a feature <code class= + "code"><location></code> is used to set the installation + directory in the third parameter.</p> + <pre class="programlisting"> +exe hello : hello.cpp ; +install install-bin : hello : <location>"C:/Program Files/hello" ; +</pre> + + <p>The main reason why it's better to use <code class= + "code"><location></code> is that the first parameter always + defines a target. Other rules might refer to a target. That's why it is + a good idea to use target names which don't have to be changed later. + Imagine a program should be installed to a different directory. It's + easier to change the installation directory if the <code class= + "code"><location></code> feature has been used as no other rules + which might refer to install-bin have to be updated.</p> + + <p>There is another reason why it makes sense to use a feature. + Boost.Build supports conditional properties which make it possible to + use different installation directories depending on the platform a + program is built on.</p> + <pre class="programlisting"> +exe hello : hello.cpp ; +install install-bin : hello : <target-os>windows:<location>"C:/Program Files/hello" <target-os>linux:<location>/usr/local/bin ; +</pre> + + <p>The feature <code class="code"><target-os></code> is another + feature with mutually exclusive values. It can be set for example to + windows or linux but not to both.</p> + + <p>The feature <code class="code"><location></code> follows + <code class="code"><target-os></code> only delimited by a colon. + Such a construct is called conditional property: Boost.Build selects + the installation directory depending on the operating system.</p> + + <p>Of course conditional properties can also be used with other rules. + It is for example possible to define different preprocessor directives + depending on the variant when building a program or a library.</p> + + <p>Boost.Build provides many more built-in rules. Another useful rule + is <code class="code">glob</code> which makes it possible to use + wildcards. In a big project with many source files it's then not + required to list them all one by one but refer to all of them with + <code class="code">glob</code>.</p> + <pre class="programlisting"> +exe hello : [ glob *.cpp ] ; +</pre> + + <p>The above Jamfile contains a nested function call: The result of the + rule <code class="code">glob</code> is passed as the second parameter + to <code class="code">exe</code>. Due to requirements of the + programming language Boost.Build is based on brackets must be used for + nested function calls.</p> + </div> + <hr> + + <h2 id="project_management">Project management<br> + <small>Multiple Jamfiles</small> + </h2> + + <div> + + <p>In large projects with many Jamfiles it's necessary to connect + Jamfiles somehow. There is typically a <code class= + "filename">Jamroot.jam</code> file in the project's root directory and + many <code class="filename">Jamfile.jam</code> files in subdirectories. + If <span class="command"><strong>b2</strong></span> is run in the + root directory developers probably expect that the entire project + including all components in subdirectories is built. As <span class= + "command"><strong>b2</strong></span> looks for Jamfiles in parent + directories but not in subdirectories Jamfiles need to refer to + Jamfiles in subdirectories explicitly.</p> + <pre class="programlisting"> +build-project hello ; +</pre> + + <p>If a Jamfile looks like the sample above it refers to a Jamfile in a + subdirectory <code class="filename">hello</code>. <code class= + "code">build-project</code> is a rule which expects a path as its sole + parameter. The path is then used to lookup a Jamfile.</p> + <pre class="programlisting"> +build-project hello ; +build-project world ; +</pre> + + <p>If you want several projects to be built you must use <code class= + "code">build-project</code> multiple times.</p> + + <p>Apart from referring to Jamfiles in subdirectories it makes also + sense to group options which should be used when building components in + a project.</p> + <pre class="programlisting"> +project : default-build release ; +build-project hello ; +build-project world ; +</pre> + + <p>The <code class="code">project</code> rule accepts various + parameters to set options for the Jamfile in the current working + directory and in subdirectories.</p> + + <p>While other rules like <code class="code">exe</code> and + <code class="code">lib</code> expect parameters to be passed in a + certain order <code class="code">project</code> uses named arguments. + In the sample above the argument's name is default-build. That's why it + is possible to pass the value release in a very different + parameter.</p> + <pre class="programlisting"> +project : : : : : : : : : default-build release ; +build-project hello ; +build-project world ; +</pre> + + <p>It doesn't make sense to pass release as the tenth parameter. But it + works as <code class="code">project</code> doesn't care about the + order. As the tenth parameter is called default-build it is + accepted.</p> + + <p><code class="code">project</code> supports only a few named + arguments. Another one is requirements which can be used to set options + which can't be overwritten.</p> + <pre class="programlisting"> +project : requirements <variant>release ; +build-project hello ; +build-project world ; +</pre> + + <p>The Jamfile above builds only release versions. It is not possible + to build a debug version anymore as requirements can not be + overwritten. That's the difference to the named argument called + default-build which was used in the previous sample: It can be + overwritten.</p> + + <p>When <code class="code">build-project</code> is used Boost.Build + assumes that the parameter is a reference to a subdirectory. We had + seen another type of reference before.</p> + <pre class="programlisting"> +exe hello : hello.cpp ; +install install-bin : hello : <location>"C:/Program Files/hello" ; +</pre> + + <p>In the above Jamfile the <code class="code">install</code> rule + refers to the target hello defined in the first line.</p> + + <p>In a large project it might be necessary to refer to targets which + are defined in Jamfiles in other directories. It is possible to + concatenate a path to a Jamfile and a target with a double slash.</p> + <pre class="programlisting"> +install install-bin : subdir//hello : <location>"C:/Program Files/hello" ; +</pre> + + <p>Now the <code class="code">install</code> rule refers to a target + hello in a Jamfile in the subdirectory <code class= + "filename">subdir</code>.</p> + + <p>Let's assume that the executable <span class= + "command"><strong>hello</strong></span> depends on a library in another + directory <code class="filename">world</code>. The library is also + built with Boost.Build using the rule <code class= + "code">lib</code>.</p> + <pre class="programlisting"> +lib world : world.cpp ; +</pre> + + <p>In the Jamfile to build the executable a reference is required to + the Jamfile of the library. It's not necessary to refer to the target + world directly as all targets in a Jamfile are built by default.</p> + <pre class="programlisting"> +exe hello : hello.cpp world : : <variant>debug <variant>release ; +</pre> + + <p>The above Jamfile assumes that the library and its Jamfile are in a + subdirectory <code class="filename">world</code>.</p> + + <p>When the executable is built there are two versions generated - a + debug and a release version. The Jamfile of the library however doesn't + set the <code class="code"><variant></code> feature. But + Boost.Build assumes that it should build two versions of the library, + too. The feature <code class="code"><variant></code> is said to + be propagated.</p> + + <p>Propagating features simplify project management as you don't need + to set the same features in various Jamfiles. However it also makes it + a bit more complicated to understand how components are built as it all + depends on what features are propagated. You can assume that + Boost.Build knows what it should do. But of course it doesn't mean that + you easily understand what it does.</p> + + <p>Let's look at another example using the feature <code class= + "code"><define></code>.</p> + <pre class="programlisting"> +exe hello : hello.cpp world : <define>WIN32 : <variant>debug <variant>release ; +</pre> + + <p>The above Jamfile defines a preprocessor directive <code class= + "code">WIN32</code> for the program <span class= + "command"><strong>hello</strong></span>. But will <code class= + "code">WIN32</code> be defined for the library, too?</p> + + <p>It won't as <code class="code"><define></code> is not a + propagating feature. If you wonder how you should know: The only way to + find out which features are propagated is to lookup the + documentation.</p> + + <p>If you installed the Boost C++ libraries you probably want to link + against some of them. You somehow have to add a dependency to the + respective Boost C++ library to your project's Jamfile. If you didn't + delete the directories you had unzipped the source files of the Boost + C++ libraries to you can refer to a target in a Jamfile in the root + directory.</p> + <pre class="programlisting"> +exe hello : hello.cpp world C:/boost_1_39_0//filesystem/ ; +</pre> + + <p>Now <span class="command"><strong>hello</strong></span> also depends + on the Boost.Filesystem library. As the target filesystem is defined in + a Jamfile in the root directory of the Boost C++ libraries the + <code class="code">exe</code> rule can refer to it. Not only will the + appropriate Boost C++ libraries be linked - an include directory is + also passed to the compiler to find the header files. If <code class= + "filename">hello.cpp</code> includes <code class= + "filename">boost/filesystem.hpp</code> the header file will be + found.</p> + + <p>In the above Jamfile the path to the root directory of the Boost C++ + libraries is hardcoded. Somehow <span class= + "command"><strong>b2</strong></span> needs to know where to find the + Boost C++ libraries. But it would be better if the path was hardcoded + only once in case several components in a project need to link against + some Boost C++ libraries.</p> + <pre class="programlisting"> +project : requirements <variant>release ; +use-project /boost : C:/boost_1_39_0 ; +build-project hello ; +build-project world ; +</pre> + + <p>The <code class="code">use-project</code> rule is used to define an + alias to a Jamfile in another directory. Jamfiles in subdirectories use + then the alias to refer to a Boost C++ library.</p> + <pre class="programlisting"> +exe hello : hello.cpp world /boost//filesystem ; +</pre> + + <p><span class="command"><strong>b2</strong></span> figures out that + <code class="filename">hello.cpp</code> is a source file, <code class= + "filename">world</code> a subdirectory and /boost//filesystem a + reference to a target filesystem in a Jamfile in <code class= + "filename">C:\boost_1_39_0</code>.</p> + + <p>Please note that a reference must start with a slash if it should + refer to a project.</p> + + <p>As libraries can be linked differently it is possible to set + features relevant to the linker.</p> + <pre class="programlisting"> +exe hello : hello.cpp world /boost//filesystem/<link>static ; +</pre> + + <p>By default libraries are linked dynamically. If libraries should be + linked statically the feature <code class="code"><link></code> + has to be set to static.</p> + + <p>Features can be appended with a slash. If more than one feature + should be set it is appended with another slash to the previous + feature.</p> + <pre class="programlisting"> +exe hello : hello.cpp world /boost//filesystem/<link>static/<threading>multi ; +</pre> + + <p><code class="code"><threading></code> is another feature which + can be set to single or multi. If <span class= + "command"><strong>hello</strong></span> should be linked against the + thread-safe version of Boost.Filesystem the feature can be set + accordingly.</p> + + <p>Linking a Boost C++ library by referencing a Jamfile might not + always work. If the Boost C++ libraries were installed differently + because they weren't built from source for example there won't be any + Jamfile to reference.</p> + <pre class="programlisting"> +lib filesystem : : <name>libboost_filesystem <search>C:/libs ; +exe hello : hello.cpp world filesystem : <include>C:/include ; +</pre> + + <p>The <code class="code">lib</code> rule can not only be used to build + a library from source. It also has to be used to refer to an existing + and pre-built library.</p> + + <p>If <code class="code">lib</code> shouldn't build a library from + source the second parameter must be empty. Instead in the third + parameter the features <code class="code"><name></code> and + <code class="code"><search></code> are used to specify the + library's name and a location where Boost.Build will find the + library.</p> + + <p>It is important to specify the library's name in a + platform-independent way. For example for the Jamfile above Boost.Build + will try to find a file <code class= + "filename">libboost_filesystem.lib</code> on Windows. The usual file + extension is again automatically appended.</p> + + <p>If you want to reference a file by specifying its exact name you can + use the <code class="code"><file></code> feature.</p> + + <p>If a system library should be referenced for which you can expect + Boost.Build to know where to find it the feature <code class= + "code"><search></code> can be dropped.</p> + + <p>It is also possible to use the <code class="code">project</code> + rule to make sure all targets in a project are automatically linked + against a library.</p> + <pre class="programlisting"> +lib filesystem : : <name>libboost_filesystem <search>C:/libs ; +explicit filesystem ; +project : requirements <include>C:/include <library>filesystem ; +lib world : world.cpp ; +</pre> + + <p>A feature called <code class="code"><library></code> must be + used to add a library dependency to a <code class="code">project</code> + rule. <code class="code"><library></code> must refer to a + <code class="code">lib</code> rule which uses the already known + features <code class="code"><name></code> and <code class= + "code"><search></code>.</p> + + <p>It is now very important to make the <code class="code">lib</code> + rule explicit. This is done by using the <code class= + "code">explicit</code> rule. It is important as by default all targets + in a Jamfile are built. As the <code class="code">project</code> rule + defines requirements for all targets in the Jamfile they are also + requirements for the <code class="code">lib</code> rule. Thus the + <code class="code">lib</code> rule refers to itself. If the + <code class="code">lib</code> rule is made explicit though it's not + built and no recursive reference occurs.</p> + + <p>Please note that the order of rules in a Jamfile matters only if a + rule refers to a target: Before a target can be referenced it must have + been defined.</p> + </div> + <hr> + + <h2 id="best_practices">Best practices<br> + <small>How Boost.Build is used by others</small> + </h2> + + <div> + + <p>As Boost.Build is a high-level build system you benefit most if you + keep Jamfiles platform- and compiler-independent. After all the idea is + to build your C++ or C projects on any platform with any compiler + without being required to modify or maintain several Jamfiles.</p> + + <p>A typical problem you'll run into is that third-party libraries you + want to use will be installed in different directories. If you want to + build your project on Windows and Unix platforms paths also look very + different. Furthermore you might need to link against some system + libraries on a platform but not on another.</p> + + <p>Instead of trying to put paths for various platforms in a project's + Jamfiles it is better to rely on configuration files on every system + for system-specific settings. As it turns out <span class= + "command"><strong>b2</strong></span> does indeed look for two more + configuration files when it starts.</p> + + <p>The file <code class="filename">site-config.jam</code> should be + used to set options for an entire system. As it is machine-dependent + <span class="command"><strong>b2</strong></span> expects to find it + in <code class="filename">C:\Windows</code> on Windows platforms and in + <code class="filename">/etc</code> on Unix systems. As <code class= + "filename">site-config.jam</code> is machine-dependent paths to local + libraries are no problem.</p> + + <p>Users might not be able to create or change <code class= + "filename">site-config.jam</code> though. They would either need to + wait for system administrators to update the file or be forced again to + add system-specific paths to their own Jamfiles. As neither is a good + solution, <span class="command"><strong>b2</strong></span> also looks + for a file <code class="filename">user-config.jam</code> in a user's + home directory. On Windows it is a subdirectory of <code class= + "filename">C:\Users</code>, on Unix a subdirecory of <code class= + "filename">/home</code>. As the file <code class= + "filename">user-config.jam</code> can be maintained by users it is + probably used more often than <code class= + "filename">site-config.jam</code>.</p> + + <p>You use <code class="filename">site-config.jam</code> and + <code class="filename">user-config.jam</code> just like any other + Jamfile. As these configuration files do not belong to a project but to + a machine or a user on a machine they are allowed to contain + machine-specific options. For example they could contain a <code class= + "code">using</code> rule.</p> + <pre class="programlisting"> +using msvc ; +</pre> + + <p>The <code class="code">using</code> rule above tells <span class= + "command"><strong>b2</strong></span> to use the msvc toolset. If you + know that there is only Visual C++ installed on a system it makes sense + to put this line into a configuration file. Then <span class= + "command"><strong>b2</strong></span> doesn't need to guess anymore + which toolset to use and won't omit a warning.</p> + + <p>If you define targets in <code class= + "filename">site-config.jam</code> or <code class= + "filename">user-config.jam</code> and want to refer to these targets in + Jamfiles the <code class="code">project</code> rule must be used to set + a name.</p> + <pre class="programlisting"> +using msvc ; +project user-config ; +lib xml : : <name>libxml <search>C:/lib : : <include>C:/include ; +</pre> + + <p>The <code class="code">lib</code> rule is used to refer to a + pre-built library whose basename is libxml and can be found in + <code class="filename">C:\lib</code>. A program which uses this XML + library probably needs to include header files from this library. + That's why in the usage requirements - this is the fifth parameter - + the feature <code class="code"><include></code> is set to + <code class="filename">C:\include</code>: Whoever uses this rule will + inherit the <code class="code"><include></code> feature.</p> + + <p>As the <code class="code">project</code> rule has been used to set + the name user-config a Jamfile can refer to the XML library via + /user-config//xml.</p> + <pre class="programlisting"> +exe xmlparser : xmlparser.cpp : <library>/user-config//xml ; +</pre> + + <p>In order to build <span class= + "command"><strong>xmlparser</strong></span> the program must be linked + against the XML library. Even though the location of the library and + its header files might vary the Jamfile does not contain any + system-specific paths. The Jamfile expects to find the target xml in + the project user-config. If this is a configuration file it's no + problem to use system-specific paths as after all configuration files + are bound to a machine or to a user on a machine.</p> + + <p>As Boost.Build has been created to build and install the Boost C++ + libraries there is built-in support to use pre-built Boost C++ + libraries more easily.</p> + <pre class="programlisting"> +using msvc ; +project user-config ; +using boost : 1.39 : <include>C:/include/boost-1_39 <library>C:/lib ; +</pre> + + <p>The <code class="code">using</code> rule must be used to refer to a + toolset called boost. This toolset is different from toolsets like msvc + which you've read about so far: It doesn't contain any programs which + will be run later. As support for pre-built Boost C++ libraries has + been implemented in a toolset though it's required to use the + <code class="code">using</code> rule.</p> + + <p>Just as with other libraries the location of the Boost C++ libraries + might vary. Thus it makes sense to put the <code class= + "code">using</code> rule into one of the two configuration files.</p> + + <p>It is possible to pass parameters to the <code class= + "code">using</code> rule: The first one is the version number, the + second a list of options. In the Jamfile above the Boost C++ libraries + 1.39 are used which can be found in the directories passed as + options.</p> + + <p>Once the boost toolset is used it is possible to use Boost C++ + libraries without defining targets yourself.</p> + <pre class="programlisting"> +import boost ; +boost.use-project 1.39 ; +exe hello : hello.cpp : <library>/boost//thread ; +</pre> + + <p>If a program uses a Boost C++ library it can refer to targets in a + project called boost. In order to recognize the project boost though + the boost module must be imported and the rule <code class= + "code">boost.use-project</code> used: Importing the boost module makes + the <code class="code">boost.use-project</code> rule available. This + rule expects a version number as its sole argument. As it is possible + to use the <code class="code">using</code> rule to refer to various + versions of the Boost C++ libraries a project can specify which version + it wants to use. In the Jamfile above the program <span class= + "command"><strong>hello</strong></span> uses Boost.Thread from version + 1.39.</p> + </div> + <hr> + + <h2 id="rule_reference">Rule reference<br> + <small>Building blocks for Jamfiles</small> + </h2> + + <div> + + <p>If you manage a project with Boost.Build and create Jamfiles you use + rules all the time. Thus you should know which rules exist and how they + are used. The following table gives you an overview about the most + important rules.</p> + + <p>There is a star, plus sign or question mark behind some parameters. + The star means there can be arbitrary many values, the plus sign there + must be at least one value and the question mark there must be zero or + exactly one value.</p> + + <table border="0" cellspacing="0" cellpadding="0" id="id369340"> + <caption> + Table 1. Rules + </caption> + + <tbody> + <tr> + <th class="col-md-2">Name</th> + + <th>Parameters</th> + + <th>Description</th> + </tr> + + <tr> + <td>alias</td> + + <td>name : sources * : requirements * : default-build * : + usage-requirements *</td> + + <td>Refer to sources or any other targets via a new name.</td> + </tr> + + <tr> + <td>build-project</td> + + <td>dir</td> + + <td>Refer to a Jamfile in another directory to build a + project.</td> + </tr> + + <tr> + <td>conditional</td> + + <td>condition + : requirements *</td> + + <td>Create conditional requirements without using conditional + properties.</td> + </tr> + + <tr> + <td>exe</td> + + <td>name : sources * : requirements * : default-build * : + usage-requirements *</td> + + <td>Build an executable.</td> + </tr> + + <tr> + <td>explicit</td> + + <td>target-names *</td> + + <td>Make targets explicit.</td> + </tr> + + <tr> + <td>glob</td> + + <td>wildcards + : excludes *</td> + + <td>Reference files in a directory via wildcards.</td> + </tr> + + <tr> + <td>glob-tree</td> + + <td>wildcards + : excludes *</td> + + <td>Reference files in a directory and all subdirectories via + wildcards.</td> + </tr> + + <tr> + <td>install</td> + + <td>name-and-dir : sources * : requirements * : default-build + *</td> + + <td>Install files to a directory.</td> + </tr> + + <tr> + <td>lib</td> + + <td>names + : sources * : requirements * : default-build * : + usage-requirements *</td> + + <td>Build a library.</td> + </tr> + + <tr> + <td>project</td> + + <td>id ? : options * : *</td> + + <td>Set project options.</td> + </tr> + + <tr> + <td>unit-test</td> + + <td>target : source : properties *</td> + + <td>Build and run an executable.</td> + </tr> + + <tr> + <td>use-project</td> + + <td>id : where</td> + + <td>Reference a Jamfile in another directory to use the project + id as a target.</td> + </tr> + + <tr> + <td>using</td> + + <td>toolset-module : *</td> + + <td>Select a toolset.</td> + </tr> + </tbody> + </table> + + <p>Your Boost.Build version might support more rules than listed above. + If you want to find out which rules are supported you should check out + the files in the subdirectory <code class="filename">build</code> of + your Boost.Build installation.</p> + </div> + <hr> + + <h2 id="feature_reference">Feature reference<br> + <small>Configuration options for the build process</small> + </h2> + + <div> + + <p>Features allow you to specify exactly how binaries are built. As + there are many configuration options available the list of features is + pretty long. The following table introduces you to the most important + features.</p> + + <table border="0" cellspacing="0" cellpadding="0" id="id369624"> + <caption> + Table 2. Features + </caption> + + <tbody> + <tr> + <th class="col-md-2">Name</th> + + <th>Values</th> + + <th>Description</th> + </tr> + + <tr> + <td><address-model></td> + + <td>16, 32, 64, 32_64</td> + + <td>Generate 16-, 32- or 64-bit code.</td> + </tr> + + <tr> + <td><architecture></td> + + <td>x86, ia64, sparc, power, mips1, mips2, mips3, mips4, mips32, + mips32r2, mips64, parisc, arm, combined, combined-x86-power</td> + + <td>Set processor family to generate code for.</td> + </tr> + + <tr> + <td><c++-template-depth></td> + + <td>1, 2, 3, ...</td> + + <td>Set maximum template depth.</td> + </tr> + + <tr> + <td><cflags></td> + + <td>...</td> + + <td>Pass flags to C compiler.</td> + </tr> + + <tr> + <td><cxxflags></td> + + <td>...</td> + + <td>Pass flags to C++ compiler</td> + </tr> + + <tr> + <td><debug-symbols></td> + + <td>on, off</td> + + <td>Create debug symbols.</td> + </tr> + + <tr> + <td><def-file></td> + + <td>...</td> + + <td>Set path to <code class="filename">def</code> file (specific + to Windows DLLs).</td> + </tr> + + <tr> + <td><define></td> + + <td>...</td> + + <td>Define preprocessor directives.</td> + </tr> + + <tr> + <td><embed-manifest></td> + + <td>on, off</td> + + <td>Embed manifest (specific to msvc toolset).</td> + </tr> + + <tr> + <td><host-os></td> + + <td>aix, bsd, cygwin, darwin, freebsd, hpux, iphone, linux, + netbsd, openbsd, osf, qnx, qnxnto, sgi, solaris, unix, unixware, + windows</td> + + <td>Use in conditional properties if features depend on host + operating systems.</td> + </tr> + + <tr> + <td><include></td> + + <td>...</td> + + <td>Set include directories.</td> + </tr> + + <tr> + <td><inlining></td> + + <td>off, on, full</td> + + <td>Inline functions.</td> + </tr> + + <tr> + <td><library></td> + + <td>...</td> + + <td>Link to a library (use in <code class="code">project</code> + rule).</td> + </tr> + + <tr> + <td><link></td> + + <td>shared, static</td> + + <td>Link to shared or static version of a library.</td> + </tr> + + <tr> + <td><linkflags></td> + + <td>...</td> + + <td>Pass flags to linker.</td> + </tr> + + <tr> + <td><location></td> + + <td>...</td> + + <td>Set directory (use in <code class="code">install</code> + rule).</td> + </tr> + + <tr> + <td><name></td> + + <td>...</td> + + <td>Set basename of a library (use in <code class= + "code">lib</code> rule).</td> + </tr> + + <tr> + <td><optimization></td> + + <td>off, speed, space</td> + + <td>Generate optimized code.</td> + </tr> + + <tr> + <td><profiling></td> + + <td>off, on</td> + + <td>Generate profiled code.</td> + </tr> + + <tr> + <td><runtime-link></td> + + <td>shared, static</td> + + <td>Link to single-threaded or thread-safe runtime library.</td> + </tr> + + <tr> + <td><search></td> + + <td>...</td> + + <td>Set directory to search for libraries (use in <code class= + "code">lib</code> rule together with <code class= + "code"><name></code>).</td> + </tr> + + <tr> + <td><source></td> + + <td>...</td> + + <td>Set source in requirements parameter of <code class= + "code">project</code> rule or in conditional properties.</td> + </tr> + + <tr> + <td><target-os></td> + + <td>aix, bsd, cygwin, darwin, freebsd, hpux, iphone, linux, + netbsd, openbsd, osf, qnx, qnxnto, sgi, solaris, unix, unixware, + windows</td> + + <td>Use in conditional properties if features depend on target + operating systems.</td> + </tr> + + <tr> + <td><threading></td> + + <td>single, multi</td> + + <td>Build singlethreaded or thread-safe version.</td> + </tr> + + <tr> + <td><toolset></td> + + <td>gcc, msvc, intel-linux, intel-win, acc, borland, como-linux, + cw, dmc, hp_cxx, sun</td> + + <td>Use in conditional properties if features depend on + toolsets.</td> + </tr> + + <tr> + <td><undef></td> + + <td>...</td> + + <td>Undefine preprocessor directives.</td> + </tr> + + <tr> + <td><use></td> + + <td>...</td> + + <td>Take over only usage requirements of a referenced target but + don't do anything else.</td> + </tr> + + <tr> + <td><variant></td> + + <td>debug, release, profile</td> + + <td>Build debug, release or profile version.</td> + </tr> + + <tr> + <td><warnings></td> + + <td>on, all, off</td> + + <td>Switch off warnings.</td> + </tr> + + <tr> + <td><warnings-as-errors></td> + + <td>off, on</td> + + <td>Treat warnings as errors.</td> + </tr> + </tbody> + </table> + + <p>For a complete and up-to-date reference of Boost.Build features look + up the file <code class="filename">builtin.jam</code> in the + subdirectory <code class="filename">tools</code> of your Boost.Build + installation. Search for lines starting with <code class= + "code">feature.feature</code> - this is the internal rule used to + define features.</p> + </div> + + <hr id="hrfoot"> + <p>Copyright Boris Schäling 2009. Distributed under the Boost Software + License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at + <a href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</a>) + + </div> + + +</body> +</html> |