Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of boost. Click here for the latest Boost documentation.
PrevUpHomeNext

Chapter 50. Boost.Jam : 3.1.19

Rene Rivera

David Abrahams

Vladimir Prus

Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)

Table of Contents

Building B2
Language
Lexical Features
Targets
Rules
Flow-of-Control
Variables
Modules
Miscellaneous
Diagnostics
Bugs, Limitations
Fundamentals
History

Installing B2 after building it is simply a matter of copying the generated executables someplace in your PATH. For building the executables there are a set of build bootstrap scripts to accomodate particular environments. The scripts take one optional argument, the name of the toolset to build with. When the toolset is not given an attempt is made to detect an available toolset and use that. The build scripts accept these arguments:

build [toolset]

Running the scripts without arguments will give you the best chance of success. On Windows platforms from a command console do:

cd jam source location
.\build.bat

On Unix type platforms do:

cd jam source location
sh ./build.sh

For the Boost.Jam source included with the Boost distribution the jam source location is BOOST_ROOT/tools/build/src/engine.

If the scripts fail to detect an appropriate toolset to build with your particular toolset may not be auto-detectable. In that case, you can specify the toolset as the first argument, this assumes that the toolset is readily available in the PATH.

[Note] Note

The toolset used to build Boost.Jam is independent of the toolsets used for Boost.Build. Only one version of Boost.Jam is needed to use Boost.Build.

The supported toolsets, and whether they are auto-detected, are:

Table 50.1. Supported Toolsets

Script

Platform

Toolset

Detection and Notes

build.bat

Windows NT, 2000, and XP

borland
Borland C++Builder (BCC 5.5)

  • Common install location: "C:\Borland\BCC55"
  • BCC32.EXE in PATH

como
Comeau Computing C/C++

gcc
GNU GCC

gcc-nocygwin
GNU GCC

intel-win32
Intel C++ Compiler for Windows

  • ICL.EXE in PATH

metrowerks
MetroWerks CodeWarrior C/C++ 7.x, 8.x, 9.x

  • CWFolder variable configured
  • MWCC.EXE in PATH

mingw
GNU GCC as the MinGW configuration

  • Common install location: "C:\MinGW"

msvc
Microsoft Visual C++ 6.x

  • VCVARS32.BAT already configured
  • %MSVCDir% is present in environment
  • Common install locations: "%ProgramFiles%\Microsoft Visual Studio", "%ProgramFiles%\Microsoft Visual C++"
  • CL.EXE in PATH

vc7
Microsoft Visual C++ 7.x

  • VCVARS32.BAT or VSVARS32.BAT already configured
  • %VS71COMNTOOLS% is present in environment
  • %VCINSTALLDIR% is present in environment
  • Common install locations: "%ProgramFiles%\Microsoft Visual Studio .NET", "%ProgramFiles%\Microsoft Visual Studio .NET 2003"
  • CL.EXE in PATH

vc8 and vc9
Microsoft Visual C++ 8.x and 9.x

Detection:

  • VCVARSALL.BAT already configured
  • %VS90COMNTOOLS% is present in environment
  • Common install location: "%ProgramFiles%\Microsoft Visual Studio 9"
  • %VS80COMNTOOLS% is present in environment
  • Common install location: "%ProgramFiles%\Microsoft Visual Studio 8"
  • CL.EXE in PATH

Notes:

  • If VCVARSALL.BAT is called to set up the toolset, it is passed all the extra arguments, see below for what those arguments are. This can be used to build, for example, a Win64 specific version of b2. Consult the VisualStudio documentation for what the possible argument values to the VCVARSALL.BAT are.

build.sh

Unix, Linux, Cygwin, etc.

acc
HP-UX aCC

  • aCC in PATH
  • uname is "HP-UX"

como
Comeau Computing C/C++

  • como in PATH

gcc
GNU GCC

  • gcc in PATH

intel-linux
Intel C++ for Linux

  • icc in PATH
  • Common install locations: "/opt/intel/cc/9.0", "/opt/intel_cc_80", "/opt/intel/compiler70", "/opt/intel/compiler60", "/opt/intel/compiler50"

kcc
Intel KAI C++

  • KCC in PATH

kylix
Borland C++Builder

  • bc++ in PATH

mipspro
SGI MIPSpro C

  • uname is "IRIX" or "IRIX64"

sunpro
Sun Workshop 6 C++

  • Standard install location: "/opt/SUNWspro"

qcc
QNX Neutrino

  • uname is "QNX" and qcc in PATH

true64cxx
Compaq C++ Compiler for True64 UNIX

  • uname is "OSF1"

vacpp
IBM VisualAge C++

  • xlc in PATH

MacOS X

darwin
Apple MacOS X GCC

  • uname is "Darwin"

Windows NT, 2000, and XP

mingw
GNU GCC as the MinGW configuration with the MSYS shell

  • Common install location: "/mingw"


The built executables are placed in a subdirectory specific to your platform. For example, in Linux running on an Intel x86 compatible chip, the executables are placed in: "bin.linuxx86". The =b2[.exe]= executable can be used to invoke Boost.Build.

The build scripts support additional invocation arguments for use by developers of Boost.Jam and for additional setup of the toolset. The extra arguments come after the toolset:

  • Arguments not in the form of an option, before option arguments, are used for extra setup to toolset configuration scripts.
  • Arguments of the form "--option", which are passed to the build.jam build script.
  • Arguments not in the form of an option, after the options, which are targets for the build.jam script.
build [toolset] [setup*] [--option+ target*]

The arguments immediately after the toolset are passed directly to the setup script of the toolset, if available and if it needs to be invoked. This allows one to configure the toolset as needed to do non-default builds of b2. For example to build a Win64 version with vc8. See the toolset descriptiona above for when particular toolsets support this.

The arguments starting with the "--option" forms are passed to the build.jam script and are used to further customize what gets built. Options and targets supported by the build.jam script:

---

Empty option when one wants to only specify a target.

--release

The default, builds the optimized executable.

--debug

Builds debugging versions of the executable. When built they are placed in their own directory "bin./platform/.debug".

--grammar

Normally the Jam language grammar parsing files are not regenerated. This forces building of the grammar, although it may not force the regeneration of the grammar parser. If the parser is out of date it will be regenerated and subsequently built.

--with-python=path

Enables Python integration, given a path to the Python libraries.

--gc

Enables use of the Boehm Garbage Collector. The build will look for the Boehm-GC source in a "boehm_gc" subdirectory from the b2 sources.

--duma

Enables use of the DUMA (Detect Unintended Memory Access) debugging memory allocator. The build expects to find the DUMA source files in a "duma" subdirectory from the b2 sources.

--toolset-root=path

Indicates where the toolset used to build is located. This option is passed in by the bootstrap (build.bat or build.sh) script.

--show-locate-target

For information, prints out where it will put the built executable.

--noassert

Disable debug assertions, even if building the debug version of the executable.

dist

Generate packages (compressed archives) as appropriate for distribution in the platform, if possible.

clean

Remove all the built executables and objects.


PrevUpHomeNext