The gcc module supports the GNU C++ compiler on Linux, a number of Unix-like system including SunOS and on Windows (either Cygwin or MinGW). On Mac OSX, it is recommended to use system gcc, see the section called “Apple Darwin gcc”.

The gcc module is initialized using the following syntax:

using gcc : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the version is not explicitly specified, it will be automatically detected by running the compiler with the -v option. If the command is not specified, the g++ binary will be searched in PATH.

The following options can be provided, using <option-name>option-value syntax:

The darwin module supports the version of gcc that is modified and provided by Apple. The configuration is essentially identical to that of the gcc module.

The darwin toolset can generate so called "fat" binaries—binaries that can run support more than one architecture, or address mode. To build a binary that can run both on Intel and PowerPC processors, specify architecture=combined. To build a binary that can run both in 32-bit and 64-bit modes, specify address-model=32_64. If you specify both of those properties, a "4-way" fat binary will be generated.

The msvc module supports the Microsoft Visual C++ command-line tools on Microsoft Windows. The supported products and versions of command line tools are listed below:

The user would then call the boost build executable with the toolset set equal to msvc-[version number] for example to build with Visual Studio 2017 one could run:

.\b2 toolset=msvc-14.1 target
          

The msvc module is initialized using the following syntax:

using msvc : [version] : [c++-compile-command] : [compiler options] ;
          

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the version is not explicitly specified, the most recent version found in the registry will be used instead. If the special value all is passed as the version, all versions found in the registry will be configured. If a version is specified, but the command is not, the compiler binary will be searched in standard installation paths for that version, followed by PATH.

The compiler command should be specified using forward slashes, and quoted.

The following options can be provided, using <option-name>option-value syntax:

.\b2 toolset=msvc-12.0 windows-api=store architecture=arm

The intel-linux and intel-win modules support the Intel C++ command-line compiler—the Linux and Windows versions respectively.

The module is initialized using the following syntax:

using intel-linux : [version] : [c++-compile-command] : [compiler options] ;

or

using intel-win : [version] : [c++-compile-command] : [compiler options] ;

respectively.

This statement may be repeated several times, if you want to configure several versions of the compiler.

If compiler command is not specified, then Boost.Build will look in PATH for an executable icpc (on Linux), or icc.exe (on Windows).

The following options can be provided, using <option-name>option-value syntax:

The Linux version supports the following additional options:

The acc module supports the HP aC++ compiler for the HP-UX operating system.

The module is initialized using the following syntax:

using acc : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, the aCC binary will be searched in PATH.

The following options can be provided, using <option-name>option-value syntax:

The borland module supports the command line C++ compiler included in C++ Builder 2006 product and earlier version of it, running on Microsoft Windows.

The supported products are listed below. The version reported by the command lines tools is also listed for reference.:

The module is initialized using the following syntax:

using borland : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named bcc32 in PATH.

The following options can be provided, using <option-name>option-value syntax:

The como-linux and the como-win modules supports the Comeau C/C++ Compiler on Linux and Windows respectively.

The module is initialized using the following syntax:

using como-linux : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named como in PATH.

The following options can be provided, using <option-name>option-value syntax:

Before using the Windows version of the compiler, you need to setup necessary environment variables per compiler's documentation. In particular, the COMO_XXX_INCLUDE variable should be set, where XXX corresponds to the used backend C compiler.

The cw module support CodeWarrior compiler, originally produced by Metrowerks and presently developed by Freescale. Boost.Build supports only the versions of the compiler that target x86 processors. All such versions were released by Metrowerks before acquisition and are not sold any longer. The last version known to work is 9.4.

The module is initialized using the following syntax:

using cw : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named mwcc in default installation paths and in PATH.

The following options can be provided, using <option-name>option-value syntax:

The dmc module supports the Digital Mars C++ compiler.

The module is initialized using the following syntax:

using dmc : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named dmc in PATH.

The following options can be provided, using <option-name>option-value syntax:

The hp_cxx modules supports the HP C++ Compiler for Tru64 Unix.

The module is initialized using the following syntax:

using hp_cxx : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named hp_cxx in PATH.

The following options can be provided, using <option-name>option-value syntax:

The sun module supports the Sun Studio C++ compilers for the Solaris OS.

The module is initialized using the following syntax:

using sun : [version] : [c++-compile-command] : [compiler options] ;

This statement may be repeated several times, if you want to configure several versions of the compiler.

If the command is not specified, Boost.Build will search for a binary named CC in /opt/SUNWspro/bin and in PATH.

When using this compiler on complex C++ code, such as the Boost C++ library, it is recommended to specify the following options when initializing the sun module:

-library=stlport4 -features=tmplife -features=tmplrefstatic
          

See the Sun C++ Frontend Tales for details.

The following options can be provided, using <option-name>option-value syntax:

The vacpp module supports the IBM Visual Age C++ Compiler, for the AIX operating system. Versions 7.1 and 8.0 are known to work.

The module is initialized using the following syntax:

using vacpp ;

The module does not accept any initialization options. The compiler should be installed in the /usr/vacpp/bin directory.

Later versions of Visual Age are known as XL C/C++. They were not tested with the the vacpp module.

The STLport library is an alternative implementation of C++ runtime library. Boost.Build supports using that library on Windows platform. Linux is hampered by different naming of libraries in each STLport version and is not officially supported.

Before using STLport, you need to configure it in user-config.jam using the following syntax:

using stlport : [version] : header-path : [library-path] ;

Where version is the version of STLport, for example 5.1.4, headers is the location where STLport headers can be found, and libraries is the location where STLport libraries can be found. The version should always be provided, and the library path should be provided if you're using STLport's implementation of iostreams. Note that STLport 5.* always uses its own iostream implementation, so the library path is required.

When STLport is configured, you can build with STLport by requesting stdlib=stlport on the command line.

Provides support for the zlib library. zlib can be configured either to use precompiled binaries or to build the library from source.

zlib can be initialized using the following syntax

using zlib : [version] : [options] : [condition] : [is-default] ;
          

Options for using a prebuilt library:

If none of these options is specified, then the environmental variables ZLIB_LIBRARY_PATH, ZLIB_NAME, and ZLIB_INCLUDE will be used instead.

Options for building zlib from source:

Examples:

# Find zlib in the default system location
using zlib ;
# Build zlib from source
using zlib : 1.2.7 : <source>/home/steven/zlib-1.2.7 ;
# Find zlib in /usr/local
using zlib : 1.2.7 : <include>/usr/local/include <search>/usr/local/lib ;
# Build zlib from source for msvc and find
# prebuilt binaries for gcc.
using zlib : 1.2.7 : <source>C:/Devel/src/zlib-1.2.7 : <toolset>msvc ;
using zlib : 1.2.7 : : <toolset>gcc ;

Provides support for the bzip2 library. bzip2 can be configured either to use precompiled binaries or to build the library from source.

bzip2 can be initialized using the following syntax

using bzip2 : [version] : [options] : [condition] : [is-default] ;
          

Options for using a prebuilt library:

If none of these options is specified, then the environmental variables BZIP2_LIBRARY_PATH, BZIP2_NAME, and BZIP2_INCLUDE will be used instead.

Options for building bzip2 from source:

Examples:

# Find bzip in the default system location
using bzip2 ;
# Build bzip from source
using bzip2 : 1.0.6 : <source>/home/sergey/src/bzip2-1.0.6 ;
# Find bzip in /usr/local
using bzip2 : 1.0.6 : <include>/usr/local/include <search>/usr/local/lib ;
# Build bzip from source for msvc and find
# prebuilt binaries for gcc.
using bzip2 : 1.0.6 : <source>C:/Devel/src/bzip2-1.0.6 : <toolset>msvc ;
using bzip2 : 1.0.6 : : <toolset>gcc ;

To use xsltproc, you first need to configure it using the following syntax:

using xsltproc : [xsltproc] ;

Where xsltproc is the xsltproc executable. If xsltproc is not specified, and the variable XSLTPROC is set, the value of XSLTPROC will be used. Otherwise, xsltproc will be searched for in PATH.

The following options can be provided, using <option-name>option-value syntax:

The xsltproc module provides the following rules. Note that these operate on jam targets and are intended to be used by another toolset, such as boostbook, rather than directly by users.

To use boostbook, you first need to configure it using the following syntax:

using boostbook : [docbook-xsl-dir] : [docbook-dtd-dir] : [boostbook-dir] ;

docbook-xsl-dir is the DocBook XSL stylesheet directory. If not provided, we use DOCBOOK_XSL_DIR from the environment (if available) or look in standard locations. Otherwise, we let the XML processor load the stylesheets remotely.

docbook-dtd-dir is the DocBook DTD directory. If not provided, we use DOCBOOK_DTD_DIR From the environment (if available) or look in standard locations. Otherwise, we let the XML processor load the DTD remotely.

boostbook-dir is the BoostBook directory with the DTD and XSL subdirs.

The boostbook module depends on xsltproc. For pdf or ps output, it also depends on fop.

The following options can be provided, using <option-name>option-value syntax:

The boostbook module defines a rule for creating a target following the common syntax.

To use doxygen, you first need to configure it using the following syntax:

using doxygen : [name] ;

name is the doxygen command. If it is not specified, it will be found in the PATH.

The doxygen module depends on the boostbook module when generating BoostBook XML.

The following options can be provided, using <option-name>option-value syntax:

The doxygen module defines a rule for creating a target following the common syntax.

The quickbook module provides a generator to convert from Quickbook to BoostBook XML.

To use quickbook, you first need to configure it using the following syntax:

using quickbook : [command] ;

command is the quickbook executable. If it is not specified, Boost.Build will compile it from source. If it is unable to find the source it will search for a quickbook executable in PATH.

The fop module provides generators to convert from XSL formatting objects to Postscript and PDF.

To use fop, you first need to configure it using the following syntax:

using fop : [fop-command] : [java-home] : [java] ;

fop-command is the command to run fop. If it is not specified, Boost.Build will search for it in PATH and FOP_HOME.

Either java-home or java can be used to specify where to find java.