As described in the Boost.Build
Reference Manual, a file called
your home directory is used to specify the tools and libraries available
to the build system. You may need to create or edit
tell Boost.Build how to invoke Python,
its headers, and link with its libraries.
If you are using a unix-variant OS and you ran Boost's
If you have one fairly “standard” python installation for your platform,
you might not need to do anything special to describe it. If you haven't
configured python in
you don't specify
on the Boost.Build command line), Boost.Build will automatically execute
the equivalent of
import toolset : using ; using python ;
which automatically looks for Python in the most likely places. However,
that only happens when using the Boost.Python project file (e.g. when referred
to by another project as in the quickstart method). If instead you are linking
against separately-compiled Boost.Python binaries, you should set up a
with at least the minimal incantation above.
If you have several versions of Python installed, or Python is installed
in an unusual way, you may want to supply any or all of the following optional
the version of Python to use. Should be in Major.Minor format, for
2.3. Do not
include the subminor version (i.e. not
2.5.1). If you have multiple Python versions
installed, the version will usually be the only configuration argument
preferably, a command that invokes a Python interpreter. Alternatively, the installation prefix for Python libraries and header files. Only use the alternative formulation if there is no appropriate Python executable available.
for Python headers. Normally the correct path(s) will be automatically
the path to Python library binaries. On MacOS/Darwin, you can also
pass the path of the Python framework. Normally the correct path(s)
will be automatically deduced from
if specified, should be a set of Boost.Build properties that are matched against the build configuration when Boost.Build selects a Python configuration to use. See examples below for details.
A string to append to the name of extension modules before the true filename extension. You almost certainly don't need to use this. Usually this suffix is only used when targeting a Windows debug build of Python, and will be set automatically for you based on the value of the <python-debugging> feature. However, at least one Linux distribution (Ubuntu Feisty Fawn) has a specially configured <python-dbg> package that claims to use such a suffix.
Note that in the examples below, case and especially whitespace are significant.
If you have both python 2.5 and python 2.4 installed,
user-config.jam might contain
using python : 2.5 ; # Make both versions of Python available using python : 2.4 ; # To build with python 2.4, add python=2.4 # to your command line.
The first version configured (2.5) becomes the default. To build against
python 2.4, add
If you have python installed in an unusual location, you might supply
the path to the interpreter in the
using python : : /usr/local/python-2.6-beta/bin/python ;
If you have a separate build of Python for use with a particular toolset,
you might supply that toolset in the
using python ; # use for most toolsets # Use with Intel C++ toolset using python : # version : c:\\Devel\\Python-2.5-IntelBuild\\PCBuild\\python # cmd-or-prefix : # includes : # libraries : <toolset>intel # condition ;
If you have downloaded the Python sources and built both the normal and the "python debugging" builds from source on Windows, you might see:
using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python ; using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python_d : # includes : # libs : <python-debugging>on ;
You can set up your user-config.jam so a bjam built under Windows can
build/test both Windows and Cygwin_ python extensions. Just pass
for the cygwin python installation:
# windows installation using python ; # cygwin installation using python : : c:\\cygwin\\bin\\python2.5 : : : <target-os>cygwin ;
bjam target-os=cygwin toolset=gcc
This is supposed to work the other way, too (targeting windows python with a Cygwin bjam) but it seems as though the support in Boost.Build's toolsets for building that way is broken at the time of this writing.
Note that because of the way Boost.Build currently selects target alternatives, you might have be very explicit in your build requests. For example, given:
using python : 2.5 ; # a regular windows build using python : 2.4 : : : : <target-os>cygwin ;
will yield an error. Instead, you'll need to write
user-config.jam in your home directory (if any)
after making a backup of the old version.