Planet
navi homePPSaboutscreenshotsdownloaddevelopmentforum

source: downloads/boost_1_34_1/libs/python/doc/building.html @ 69

Last change on this file since 69 was 29, checked in by landauf, 17 years ago

updated boost from 1_33_1 to 1_34_1

File size: 40.5 KB
Line 
1<?xml version="1.0" encoding="utf-8" ?>
2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
4<head>
5<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6<meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" />
7<title>Boost C++ Libraries: Boost.Python Build and Test HOWTO</title>
8<link rel="stylesheet" href="../../../rst.css" type="text/css" />
9</head>
10<body>
11<div class="document" id="logo-boost-python-build-and-test-howto">
12<h1 class="title"><a class="reference external" href="../index.htm"><img alt="Boost C++ Libraries:" class="boost-logo" src="../../../boost.png" /></a> Boost.Python Build and Test HOWTO</h1>
13
14<!-- Copyright David Abrahams 2006. Distributed under the Boost -->
15<!-- Software License, Version 1.0. (See accompanying -->
16<!-- file LICENSE_1_0.txt or copy at -->
17<!-- http://www.boost.org/LICENSE_1_0.txt) -->
18<div class="contents sidebar small topic" id="contents">
19<p class="topic-title first">Contents</p>
20<ul class="auto-toc simple">
21<li><a class="reference internal" href="#requirements" id="id25">1&nbsp;&nbsp;&nbsp;Requirements</a></li>
22<li><a class="reference internal" href="#background" id="id26">2&nbsp;&nbsp;&nbsp;Background</a></li>
23<li><a class="reference internal" href="#no-install-quickstart" id="id27">3&nbsp;&nbsp;&nbsp;No-Install Quickstart</a><ul class="auto-toc">
24<li><a class="reference internal" href="#basic-procedure" id="id28">3.1&nbsp;&nbsp;&nbsp;Basic Procedure</a></li>
25<li><a class="reference internal" href="#in-case-of-trouble" id="id29">3.2&nbsp;&nbsp;&nbsp;In Case of Trouble</a></li>
26<li><a class="reference internal" href="#in-case-everything-seemed-to-work" id="id30">3.3&nbsp;&nbsp;&nbsp;In Case Everything Seemed to Work</a></li>
27<li><a class="reference internal" href="#modifying-the-example-project" id="id31">3.4&nbsp;&nbsp;&nbsp;Modifying the Example Project</a></li>
28</ul>
29</li>
30<li><a class="reference internal" href="#installing-boost-python-on-your-system" id="id32">4&nbsp;&nbsp;&nbsp;Installing Boost.Python on your System</a></li>
31<li><a class="reference internal" href="#configuring-boost-build" id="id33">5&nbsp;&nbsp;&nbsp;Configuring Boost.Build</a><ul class="auto-toc">
32<li><a class="reference internal" href="#python-configuration-parameters" id="id34">5.1&nbsp;&nbsp;&nbsp;Python Configuration Parameters</a></li>
33<li><a class="reference internal" href="#examples" id="id35">5.2&nbsp;&nbsp;&nbsp;Examples</a></li>
34</ul>
35</li>
36<li><a class="reference internal" href="#choosing-a-boost-python-library-binary" id="id36">6&nbsp;&nbsp;&nbsp;Choosing a Boost.Python Library Binary</a><ul class="auto-toc">
37<li><a class="reference internal" href="#the-dynamic-binary" id="id37">6.1&nbsp;&nbsp;&nbsp;The Dynamic Binary</a></li>
38<li><a class="reference internal" href="#the-static-binary" id="id38">6.2&nbsp;&nbsp;&nbsp;The Static Binary</a></li>
39</ul>
40</li>
41<li><a class="reference internal" href="#include-issues" id="id39">7&nbsp;&nbsp;&nbsp;<tt class="docutils literal"><span class="pre">#include</span></tt> Issues</a></li>
42<li><a class="reference internal" href="#python-debugging-builds" id="id40">8&nbsp;&nbsp;&nbsp;Python Debugging Builds</a></li>
43<li><a class="reference internal" href="#testing-boost-python" id="id41">9&nbsp;&nbsp;&nbsp;Testing Boost.Python</a></li>
44<li><a class="reference internal" href="#notes-for-mingw-and-cygwin-with-mno-cygwin-gcc-users" id="id42">10&nbsp;&nbsp;&nbsp;Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users</a></li>
45</ul>
46</div>
47<div class="section" id="requirements">
48<h1><a class="toc-backref" href="#id25">1&nbsp;&nbsp;&nbsp;Requirements</a></h1>
49<p>Boost.Python requires <a class="reference external" href="http://www.python.org/2.2">Python 2.2</a><a class="footnote-reference" href="#id22" id="id2"><sup>1</sup></a> <em>or</em> <a class="reference external" href="http://www.python.org"><em>newer</em></a>.</p>
50</div>
51<div class="section" id="background">
52<h1><a class="toc-backref" href="#id26">2&nbsp;&nbsp;&nbsp;Background</a></h1>
53<p>There are two basic models for combining C++ and Python:</p>
54<ul class="simple">
55<li><a class="reference external" href="http://www.python.org/doc/current/ext/intro.html">extending</a>, in which the end-user launches the Python interpreter
56executable and imports Python “extension modules” written in C++.
57Think of taking a library written in C++ and giving it a Python
58interface so Python programmers can use it.  From Python, these
59modules look just like regular Python modules.</li>
60<li><a class="reference external" href="http://www.python.org/doc/current/ext/embedding.html">embedding</a>, in which the end-user launches a program written
61in C++ that in turn invokes the Python interpreter as a library
62subroutine.  Think of adding scriptability to an existing
63application.</li>
64</ul>
65<p>The key distinction between extending and embedding is the location
66of the C++ <tt class="docutils literal"><span class="pre">main()</span></tt> function: in the Python interpreter executable,
67or in some other program, respectively.  Note that even when
68embedding Python in another program, <a class="reference external" href="http://www.python.org/doc/current/ext/extending-with-embedding.html">extension modules are often
69the best way to make C/C++ functionality accessible to Python
70code</a>, so the use of extension modules is really at the heart of
71both models.</p>
72<p>Except in rare cases, extension modules are built as
73dynamically-loaded libraries with a single entry point, which means
74you can change them without rebuilding either the other extension
75modules or the executable containing <tt class="docutils literal"><span class="pre">main()</span></tt>.</p>
76</div>
77<div class="section" id="no-install-quickstart">
78<span id="quickstart"></span><h1><a class="toc-backref" href="#id27">3&nbsp;&nbsp;&nbsp;No-Install Quickstart</a></h1>
79<p>There is no need to “install Boost” in order to get started using
80Boost.Python.  These instructions use <a class="reference external" href="../../../tools/build/index.html">Boost.Build</a> projects,
81which will build those binaries as soon as they're needed.  Your
82first tests may take a little longer while you wait for
83Boost.Python to build, but doing things this way will save you from
84worrying about build intricacies like which library binaries to use
85for a specific compiler configuration and figuring out the right
86compiler options to use yourself.</p>
87<!-- .. raw:: html
88
89<div style="width:50%"> -->
90<div class="note">
91<p class="first admonition-title">Note</p>
92<p>Of course it's possible to use other build systems to
93build Boost.Python and its extensions, but they are not
94officially supported by Boost.  Moreover <strong>99% of all “I can't
95build Boost.Python” problems come from trying to use another
96build system</strong> without first following these instructions.</p>
97<p>If you want to use another system anyway, we suggest that you
98follow these instructions, and then invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> with the</p>
99<pre class="literal-block">
100<tt class="docutils literal"><span class="pre">-a</span> <span class="pre">-o</span></tt><em>filename</em>
101</pre>
102<p class="last">options to dump the build commands it executes to a file, so
103you can see what your alternate build system needs to do.</p>
104</div>
105<!-- .. raw:: html
106
107</div> -->
108<div class="section" id="basic-procedure">
109<h2><a class="toc-backref" href="#id28">3.1&nbsp;&nbsp;&nbsp;Basic Procedure</a></h2>
110<ol class="arabic">
111<li><p class="first">Get Boost; see sections 1 and 2 [<a class="reference external" href="../../../more/getting_started/unix-variants.html#get-boost">Unix/Linux</a>, <a class="reference external" href="../../../more/getting_started/windows.html#get-boost">Windows</a>] of the
112Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a>.</p>
113</li>
114<li><p class="first">Get the <tt class="docutils literal"><span class="pre">bjam</span></tt> build driver.  See section 5 [<a class="reference external" href="../../../more/getting_started/unix-variants.html#prepare-to-use-a-boost-library-binary">Unix/Linux</a>,
115<a class="reference external" href="../../../more/getting_started/windows.html#prepare-to-use-a-boost-library-binary">Windows</a>] of the Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a>.</p>
116</li>
117<li><p class="first">cd into the <tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory of your
118Boost installation, which contains a small example project.</p>
119</li>
120<li><p class="first">Invoke <tt class="docutils literal"><span class="pre">bjam</span></tt>.  Replace the “<tt class="docutils literal"><span class="pre">stage</span></tt>“ argument from the
121example invocation from section 5 of the <a class="reference external" href="../../../more/getting_started/index.html">Getting Started
122Guide</a> with “<tt class="docutils literal"><span class="pre">test</span></tt>,“ to build all the test targets.  Also add
123the argument “<tt class="docutils literal"><span class="pre">--verbose-test</span></tt>” to see the output generated by
124the tests when they are run.</p>
125<p>On Windows, your <tt class="docutils literal"><span class="pre">bjam</span></tt> invocation might look something like:</p>
126<pre class="literal-block">
127C:\boost_1_34_0\…\quickstart&gt; <strong>bjam toolset=msvc --verbose-test test</strong>
128</pre>
129<p>and on Unix variants, perhaps,</p>
130<pre class="literal-block">
131~/boost_1_34_0/…/quickstart$ <strong>bjam toolset=gcc --verbose-test test</strong>
132</pre>
133</li>
134</ol>
135<div class="admonition-note-to-windows-users admonition">
136<p class="first admonition-title">Note to Windows Users</p>
137<p class="last">For the sake of concision, the rest of this guide will use
138unix-style forward slashes in pathnames instead of the
139backslashes with which you may be more familiar.  The forward
140slashes should work everywhere except in <a class="reference external" href="../../../more/getting_started/windows.html#command-prompt">Command Prompt</a>
141windows, where you should use backslashes.</p>
142</div>
143<p>If you followed this procedure successfully, you will have built an
144extension module called <tt class="docutils literal"><span class="pre">extending</span></tt> and tested it by running a
145Python script called <tt class="docutils literal"><span class="pre">test_extending.py</span></tt>.  You will also have
146built and run a simple application called <tt class="docutils literal"><span class="pre">embedding</span></tt> that embeds
147python.</p>
148</div>
149<div class="section" id="in-case-of-trouble">
150<h2><a class="toc-backref" href="#id29">3.2&nbsp;&nbsp;&nbsp;In Case of Trouble</a></h2>
151<p>If you're seeing lots of compiler and/or linker error messages,
152it's probably because Boost.Build is having trouble finding your
153Python installation.  You might want to pass the
154<tt class="docutils literal"><span class="pre">--debug-configuration</span></tt> option to <tt class="docutils literal"><span class="pre">bjam</span></tt> the first few times
155you invoke it, to make sure that Boost.Build is correctly locating
156all the parts of your Python installation.  If it isn't, consider
157<a class="reference internal" href="#configuring-boost-build">Configuring Boost.Build</a> as detailed below.</p>
158<p>If you're still having trouble, Someone on one of the following
159mailing lists may be able to help:</p>
160<ul class="simple">
161<li>The <a class="reference external" href="../../../more/mailing_lists.htm#jamboost">Boost.Build mailing list</a> for issues related to Boost.Build</li>
162<li>The Python <a class="reference external" href="../../../more/mailing_lists.htm#cplussig">C++ Sig</a> for issues specifically related to Boost.Python</li>
163</ul>
164</div>
165<div class="section" id="in-case-everything-seemed-to-work">
166<h2><a class="toc-backref" href="#id30">3.3&nbsp;&nbsp;&nbsp;In Case Everything Seemed to Work</a></h2>
167<p>Rejoice!  If you're new to Boost.Python, at this point it might be
168a good idea to ignore build issues for a while and concentrate on
169learning the library by going through the <a class="reference external" href="tutorial/index.html">tutorial</a> and perhaps
170some of the <a class="reference external" href="v2/reference.html">reference documentation</a>, trying out what you've
171learned about the API by modifying the quickstart project.</p>
172</div>
173<div class="section" id="modifying-the-example-project">
174<h2><a class="toc-backref" href="#id31">3.4&nbsp;&nbsp;&nbsp;Modifying the Example Project</a></h2>
175<p>If you're content to keep your extension module forever in one
176source file called <a class="reference external" href="../example/quickstart/extending.cpp"><tt class="docutils literal"><span class="pre">extending.cpp</span></tt></a>, inside your Boost
177distribution, and import it forever as <tt class="docutils literal"><span class="pre">extending</span></tt>, then you can
178stop here.  However, it's likely that you will want to make a few
179changes.  There are a few things you can do without having to learn
180<a class="reference external" href="../../../tools/build/index.html">Boost.Build</a> in depth.</p>
181<p>The project you just built is specified in two files in the current
182directory: <a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a>, which tells <tt class="docutils literal"><span class="pre">bjam</span></tt> where it can
183find the interpreted code of the Boost build system, and
184<a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, which describes the targets you just built.  These
185files are heavily commented, so they should be easy to modify.
186Take care, however, to preserve whitespace.  Punctuation such as
187<tt class="docutils literal"><span class="pre">;</span></tt> will not be recognized as intended by <tt class="docutils literal"><span class="pre">bjam</span></tt> if it is not
188surrounded by whitespace.</p>
189<div class="section" id="relocate-the-project">
190<h3>Relocate the Project</h3>
191<p>You'll probably want to copy this project elsewhere so you can
192change it without modifying your Boost distribution.  To do that,
193simply</p>
194<ol class="loweralpha simple">
195<li>copy the entire <tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory
196into a new directory.</li>
197<li>In the new copies of <a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a> and <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, locate
198the relative path near the top of the file that is clearly
199marked by a comment, and edit that path so that it refers to the
200same directory your Boost distribution as it referred to when
201the file was in its original location in the
202<tt class="docutils literal"><span class="pre">libs/python/example/quickstart/</span></tt> directory.</li>
203</ol>
204<p>For example, if you moved the project from
205<tt class="docutils literal"><span class="pre">/home/dave/boost_1_34_0/libs/python/example/quickstart</span></tt> to
206<tt class="docutils literal"><span class="pre">/home/dave/my-project</span></tt>, you could change the first path in
207<a class="reference external" href="../example/quickstart/boost-build.jam"><tt class="docutils literal"><span class="pre">boost-build.jam</span></tt></a> from</p>
208<pre class="literal-block">
209<strong>../../../..</strong>/tools/build/v2
210</pre>
211<p>to</p>
212<pre class="literal-block">
213<strong>/home/dave/boost_1_34_0</strong>/tools/build/v2
214</pre>
215<p>and change the first path in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> from</p>
216<pre class="literal-block">
217<strong>../../../..</strong>
218</pre>
219<p>to</p>
220<pre class="literal-block">
221<strong>/home/dave/boost_1_34_0</strong>
222</pre>
223</div>
224<div class="section" id="add-new-or-change-names-of-existing-source-files">
225<h3>Add New or Change Names of Existing Source Files</h3>
226<p>The names of additional source files involved in building your
227extension module or embedding application can be listed in
228<a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> right alongside <tt class="docutils literal"><span class="pre">extending.cpp</span></tt> or <tt class="docutils literal"><span class="pre">embedding.cpp</span></tt>
229respectively.  Just be sure to leave whitespace around each
230filename:</p>
231<pre class="literal-block">
232… file1.cpp file2.cpp file3.cpp …
233</pre>
234<p>Naturally, if you want to change the name of a source file you can
235tell Boost.Build about it by editing the name in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>.</p>
236</div>
237<div class="section" id="change-the-name-of-your-extension-module">
238<h3>Change the Name of your Extension Module</h3>
239<p>The name of the extension module is determined by two things:</p>
240<ol class="arabic simple">
241<li>the name in <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a> immediately following <tt class="docutils literal"><span class="pre">python-extension</span></tt>, and</li>
242<li>the name passed to <tt class="docutils literal"><span class="pre">BOOST_PYTHON_MODULE</span></tt> in <a class="reference external" href="../example/quickstart/extending.cpp"><tt class="docutils literal"><span class="pre">extending.cpp</span></tt></a>.</li>
243</ol>
244<p>To change the name of the extension module from <tt class="docutils literal"><span class="pre">extending</span></tt> to
245<tt class="docutils literal"><span class="pre">hello</span></tt>, you'd edit <a class="reference external" href="../example/quickstart/Jamroot"><tt class="docutils literal"><span class="pre">Jamroot</span></tt></a>, changing</p>
246<pre class="literal-block">
247python-extension <strong>extending</strong> : extending.cpp ;
248</pre>
249<p>to</p>
250<pre class="literal-block">
251python-extension <strong>hello</strong> : extending.cpp ;
252</pre>
253<p>and you'd edit extending.cpp, changing</p>
254<pre class="literal-block">
255BOOST_PYTHON_MODULE(<strong>extending</strong>)
256</pre>
257<p>to</p>
258<pre class="literal-block">
259BOOST_PYTHON_MODULE(<strong>hello</strong>)
260</pre>
261</div>
262</div>
263</div>
264<div class="section" id="installing-boost-python-on-your-system">
265<h1><a class="toc-backref" href="#id32">4&nbsp;&nbsp;&nbsp;Installing Boost.Python on your System</a></h1>
266<p>Since Boost.Python is a separately-compiled (as opposed to
267<a class="reference external" href="../../../more/getting_started/windows.html#header-only-libraries">header-only</a>) library, its user relies on the services of a
268Boost.Python library binary.</p>
269<p>If you need a regular installation of the Boost.Python library
270binaries on your system, the Boost <a class="reference external" href="../../../more/getting_started/index.html">Getting Started Guide</a> will
271walk you through the steps of creating one.  If building binaries
272from source, you might want to supply the <tt class="docutils literal"><span class="pre">--with-python</span></tt>
273argument to <tt class="docutils literal"><span class="pre">bjam</span></tt> (or the <tt class="docutils literal"><span class="pre">--with-libraries=python</span></tt> argument
274to <tt class="docutils literal"><span class="pre">configure</span></tt>), so only the Boost.Python binary will be built,
275rather than all the Boost binaries.</p>
276</div>
277<div class="section" id="configuring-boost-build">
278<h1><a class="toc-backref" href="#id33">5&nbsp;&nbsp;&nbsp;Configuring Boost.Build</a></h1>
279<p>As described in the <a class="reference external" href="http://www.boost.orgdoc/html/bbv2/advanced.html#bbv2.advanced.configuration">Boost.Build reference manual</a>, a file called
280<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> in your home directory<a class="footnote-reference" href="#home-dir" id="id11"><sup>6</sup></a> is used to
281specify the tools and libraries available to the build system. You
282may need to create or edit <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> to tell Boost.Build
283how to invoke Python, <tt class="docutils literal"><span class="pre">#include</span></tt> its headers, and link with its
284libraries.</p>
285<div class="admonition-users-of-unix-variant-oses admonition">
286<p class="first admonition-title">Users of Unix-Variant OSes</p>
287<p class="last">If you are using a unix-variant OS and you ran Boost's
288<tt class="docutils literal"><span class="pre">configure</span></tt> script, it may have generated a
289<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> for you.<a class="footnote-reference" href="#overwrite" id="id13"><sup>4</sup></a> If your <tt class="docutils literal"><span class="pre">configure</span></tt>/<tt class="docutils literal"><span class="pre">make</span></tt> sequence was successful and Boost.Python binaries
290were built, your <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> file is probably already
291correct.</p>
292</div>
293<p>If you have one fairly “standard” python installation for your
294platform, you might not need to do anything special to describe it.  If
295you haven't configured python in <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> (and you don't
296specify <tt class="docutils literal"><span class="pre">--without-python</span></tt> on the Boost.Build command line),
297Boost.Build will automatically execute the equivalent of</p>
298<pre class="literal-block">
299import toolset : using ;
300using python ;
301</pre>
302<p>which automatically looks for Python in the most likely places.
303However, that only happens when using the Boost.Python project file
304(e.g. when referred to by another project as in the <a class="reference internal" href="#quickstart">quickstart</a>
305method).  If instead you are linking against separately-compiled
306Boost.Python binaries, you should set up a <tt class="docutils literal"><span class="pre">user-config.jam</span></tt> file
307with at least the minimal incantation above.</p>
308<div class="section" id="python-configuration-parameters">
309<h2><a class="toc-backref" href="#id34">5.1&nbsp;&nbsp;&nbsp;Python Configuration Parameters</a></h2>
310<p>If you have several versions of Python installed, or Python is
311installed in an unusual way, you may want to supply any or all of
312the following optional parameters to <tt class="docutils literal"><span class="pre">using</span> <span class="pre">python</span></tt>.</p>
313<dl class="docutils">
314<dt>version</dt>
315<dd>the version of Python to use.  Should be in Major.Minor
316format, for example, <tt class="docutils literal"><span class="pre">2.3</span></tt>.  Do not include the subminor
317version (i.e. <em>not</em> <tt class="docutils literal"><span class="pre">2.5.1</span></tt>).  If you have multiple Python
318versions installed, the version will usually be the only
319configuration argument required.</dd>
320<dt>cmd-or-prefix</dt>
321<dd>preferably, a command that invokes a Python interpreter.
322Alternatively, the installation prefix for Python libraries and
323header files.  Only use the alternative formulation if there is
324no appropriate Python executable available.</dd>
325<dt>includes</dt>
326<dd>the <tt class="docutils literal"><span class="pre">#include</span></tt> paths for Python headers.  Normally the correct
327path(s) will be automatically deduced from <tt class="docutils literal"><span class="pre">version</span></tt> and/or
328<tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>.</dd>
329<dt>libraries</dt>
330<dd>the path to Python library binaries.  On MacOS/Darwin,
331you can also pass the path of the Python framework.  Normally the
332correct path(s) will be automatically deduced from <tt class="docutils literal"><span class="pre">version</span></tt>
333and/or <tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>.</dd>
334<dt>condition</dt>
335<dd>if specified, should be a set of Boost.Build
336properties that are matched against the build configuration when
337Boost.Build selects a Python configuration to use.  See examples
338below for details.</dd>
339<dt>extension-suffix</dt>
340<dd>A string to append to the name of extension
341modules before the true filename extension.  You almost certainly
342don't need to use this.  Usually this suffix is only used when
343targeting a Windows debug build of Python, and will be set
344automatically for you based on the value of the
345<a class="reference internal" href="#python-debugging"><tt class="docutils literal"><span class="pre">&lt;python-debugging&gt;</span></tt></a> feature.  However, at least one Linux
346distribution (Ubuntu Feisty Fawn) has a specially configured
347<a class="reference external" href="https://wiki.ubuntu.com/PyDbgBuilds">python-dbg</a> package that claims to use such a suffix.</dd>
348</dl>
349</div>
350<div class="section" id="examples">
351<h2><a class="toc-backref" href="#id35">5.2&nbsp;&nbsp;&nbsp;Examples</a></h2>
352<p>Note that in the examples below, case and <em>especially whitespace</em> are
353significant.</p>
354<ul>
355<li><p class="first">If you have both python 2.5 and python 2.4 installed,
356<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> might contain:</p>
357<pre class="literal-block">
358using python : 2.5 ;  # Make both versions of Python available
359
360using python : 2.4 ;  # To build with python 2.4, add python=2.4
361                      # to your command line.
362</pre>
363<p>The first version configured (2.5) becomes the default.  To build
364against python 2.4, add <tt class="docutils literal"><span class="pre">python=2.4</span></tt> to the <tt class="docutils literal"><span class="pre">bjam</span></tt> command line.</p>
365</li>
366<li><p class="first">If you have python installed in an unusual location, you might
367supply the path to the interpreter in the <tt class="docutils literal"><span class="pre">cmd-or-prefix</span></tt>
368parameter:</p>
369<pre class="literal-block">
370using python : : /usr/local/python-2.6-beta/bin/python ;
371</pre>
372</li>
373<li><p class="first">If you have a separate build of Python for use with a particular
374toolset, you might supply that toolset in the <tt class="docutils literal"><span class="pre">condition</span></tt>
375parameter:</p>
376<pre class="literal-block">
377using python ;  # use for most toolsets
378
379# Use with Intel C++ toolset
380using python
381     : # version
382     : c:\\Devel\\Python-2.5-IntelBuild\\PCBuild\\python # cmd-or-prefix
383     : # includes
384     : # libraries
385     : &lt;toolset&gt;intel # condition
386     ;
387</pre>
388</li>
389<li><p class="first">If you have downloaded the Python sources and built both the
390normal and the “<a class="reference internal" href="#id19">python debugging</a>” builds from source on
391Windows, you might see:</p>
392<pre class="literal-block">
393using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python ;
394using python : 2.5 : C:\\src\\Python-2.5\\PCBuild\\python_d
395  : # includes
396  : # libs
397  : &lt;python-debugging&gt;on ;
398</pre>
399</li>
400<li><p class="first">You can set up your user-config.jam so a bjam built under Windows
401can build/test both Windows and <a class="reference external" href="http://cygwin.com">Cygwin</a> python extensions.  Just pass
402<tt class="docutils literal"><span class="pre">&lt;target-os&gt;cygwin</span></tt> in the <tt class="docutils literal"><span class="pre">condition</span></tt> parameter
403for the cygwin python installation:</p>
404<pre class="literal-block">
405# windows installation
406using python ;
407
408# cygwin installation
409using python : : c:\\cygwin\\bin\\python2.5 : : : &lt;target-os&gt;cygwin ;
410</pre>
411<p>when you put target-os=cygwin in your build request, it should build
412with the cygwin version of python:<a class="footnote-reference" href="#flavor" id="id15"><sup>5</sup></a></p>
413<blockquote>
414<p>bjam target-os=cygwin toolset=gcc</p>
415</blockquote>
416<p>This is supposed to work the other way, too (targeting windows
417python with a <a class="reference external" href="http://cygwin.com">Cygwin</a> bjam) but it seems as though the support in
418Boost.Build's toolsets for building that way is broken at the
419time of this writing.</p>
420</li>
421<li><p class="first">Note that because of <a class="reference external" href="http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection">the way Boost.Build currently selects target
422alternatives</a>, you might have be very explicit in your build
423requests.  For example, given:</p>
424<pre class="literal-block">
425using python : 2.5 ; # a regular windows build
426using python : 2.4 : : : : &lt;target-os&gt;cygwin ;
427</pre>
428<p>building with</p>
429<pre class="literal-block">
430bjam target-os=cygwin
431</pre>
432<p>will yield an error.  Instead, you'll need to write:</p>
433<pre class="literal-block">
434bjam target-os=cygwin/python=2.4
435</pre>
436</li>
437</ul>
438</div>
439</div>
440<div class="section" id="choosing-a-boost-python-library-binary">
441<h1><a class="toc-backref" href="#id36">6&nbsp;&nbsp;&nbsp;Choosing a Boost.Python Library Binary</a></h1>
442<p>If—instead of letting Boost.Build construct and link with the right
443libraries automatically—you choose to use a pre-built Boost.Python
444library, you'll need to think about which one to link with.  The
445Boost.Python binary comes in both static and dynamic flavors.  Take
446care to choose the right flavor for your application.<a class="footnote-reference" href="#naming" id="id17"><sup>2</sup></a></p>
447<div class="section" id="the-dynamic-binary">
448<h2><a class="toc-backref" href="#id37">6.1&nbsp;&nbsp;&nbsp;The Dynamic Binary</a></h2>
449<p>The dynamic library is the safest and most-versatile choice:</p>
450<ul class="simple">
451<li>A single copy of the library code is used by all extension
452modules built with a given toolset.<a class="footnote-reference" href="#toolset-specific" id="id18"><sup>3</sup></a></li>
453<li>The library contains a type conversion registry.  Because one
454registry is shared among all extension modules, instances of a
455class exposed to Python in one dynamically-loaded extension
456module can be passed to functions exposed in another such module.</li>
457</ul>
458</div>
459<div class="section" id="the-static-binary">
460<h2><a class="toc-backref" href="#id38">6.2&nbsp;&nbsp;&nbsp;The Static Binary</a></h2>
461<p>It might be appropriate to use the static Boost.Python library in
462any of the following cases:</p>
463<ul class="simple">
464<li>You are <a class="reference external" href="http://www.python.org/doc/current/ext/intro.html">extending</a> python and the types exposed in your
465dynamically-loaded extension module don't need to be used by any
466other Boost.Python extension modules, and you don't care if the
467core library code is duplicated among them.</li>
468<li>You are <a class="reference external" href="http://www.python.org/doc/current/ext/embedding.html">embedding</a> python in your application and either:<ul>
469<li>You are targeting a Unix variant OS other than MacOS or AIX,
470where the dynamically-loaded extension modules can “see” the
471Boost.Python library symbols that are part of the executable.</li>
472<li>Or, you have statically linked some Boost.Python extension
473modules into your application and you don't care if any
474dynamically-loaded Boost.Python extension modules are able to
475use the types exposed by your statically-linked extension
476modules (and vice-versa).</li>
477</ul>
478</li>
479</ul>
480</div>
481</div>
482<div class="section" id="include-issues">
483<h1><a class="toc-backref" href="#id39">7&nbsp;&nbsp;&nbsp;<tt class="docutils literal"><span class="pre">#include</span></tt> Issues</a></h1>
484<ol class="arabic simple">
485<li>If you should ever have occasion to <tt class="docutils literal"><span class="pre">#include</span> <span class="pre">&quot;python.h&quot;</span></tt>
486directly in a translation unit of a program using Boost.Python,
487use <tt class="docutils literal"><span class="pre">#include</span> <span class="pre">&quot;boost/python/detail/wrap_python.hpp&quot;</span></tt> instead.
488It handles several issues necessary for use with Boost.Python,
489one of which is mentioned in the next section.</li>
490<li>Be sure not to <tt class="docutils literal"><span class="pre">#include</span></tt> any system headers before
491<tt class="docutils literal"><span class="pre">wrap_python.hpp</span></tt>.  This restriction is actually imposed by
492Python, or more properly, by Python's interaction with your
493operating system.  See
494<a class="reference external" href="http://docs.python.org/ext/simpleExample.html">http://docs.python.org/ext/simpleExample.html</a> for details.</li>
495</ol>
496</div>
497<div class="section" id="python-debugging-builds">
498<span id="id19"></span><span id="python-debugging"></span><h1><a class="toc-backref" href="#id40">8&nbsp;&nbsp;&nbsp;Python Debugging Builds</a></h1>
499<p>Python can be built in a special “python debugging” configuration
500that adds extra checks and instrumentation that can be very useful
501for developers of extension modules.  The data structures used by
502the debugging configuration contain additional members, so <strong>a
503Python executable built with python debugging enabled cannot be
504used with an extension module or library compiled without it, and
505vice-versa.</strong></p>
506<p>Since pre-built “python debugging” versions of the Python
507executable and libraries are not supplied with most distributions
508of Python,<a class="footnote-reference" href="#get-debug-build" id="id20"><sup>7</sup></a> and we didn't want to force our users
509to build them, Boost.Build does not automatically enable python
510debugging in its <tt class="docutils literal"><span class="pre">debug</span></tt> build variant (which is the default).
511Instead there is a special build property called
512<tt class="docutils literal"><span class="pre">python-debugging</span></tt> that, when used as a build property, will
513define the right preprocessor symbols and select the right
514libraries to link with.</p>
515<p>On unix-variant platforms, the debugging versions of Python's data
516structures will only be used if the symbol <tt class="docutils literal"><span class="pre">Py_DEBUG</span></tt> is defined.
517On many windows compilers, when extension modules are built with
518the preprocessor symbol <tt class="docutils literal"><span class="pre">_DEBUG</span></tt>, Python defaults to force
519linking with a special debugging version of the Python DLL.  Since
520that symbol is very commonly used even when Python is not present,
521Boost.Python temporarily undefines _DEBUG when Python.h
522is #included from <tt class="docutils literal"><span class="pre">boost/python/detail/wrap_python.hpp</span></tt> - unless
523<tt class="docutils literal"><span class="pre">BOOST_DEBUG_PYTHON</span></tt> is defined.  The upshot is that if you want
524“python debugging”and you aren't using Boost.Build, you should make
525sure <tt class="docutils literal"><span class="pre">BOOST_DEBUG_PYTHON</span></tt> is defined, or python debugging will be
526suppressed.</p>
527</div>
528<div class="section" id="testing-boost-python">
529<h1><a class="toc-backref" href="#id41">9&nbsp;&nbsp;&nbsp;Testing Boost.Python</a></h1>
530<p>To run the full test suite for Boost.Python, invoke <tt class="docutils literal"><span class="pre">bjam</span></tt> in the
531<tt class="docutils literal"><span class="pre">libs/python/test</span></tt> subdirectory of your Boost distribution.</p>
532</div>
533<div class="section" id="notes-for-mingw-and-cygwin-with-mno-cygwin-gcc-users">
534<h1><a class="toc-backref" href="#id42">10&nbsp;&nbsp;&nbsp;Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users</a></h1>
535<p>If you are using a version of Python prior to 2.4.1 with a MinGW
536prior to 3.0.0 (with binutils-2.13.90-20030111-1), you will need to
537create a MinGW-compatible version of the Python library; the one
538shipped with Python will only work with a Microsoft-compatible
539linker. Follow the instructions in the “Non-Microsoft” section of
540the “Building Extensions: Tips And Tricks” chapter in <a class="reference external" href="http://www.python.org/doc/current/inst/index.html">Installing
541Python Modules</a> to create <tt class="docutils literal"><span class="pre">libpythonXX.a</span></tt>, where <tt class="docutils literal"><span class="pre">XX</span></tt>
542corresponds to the major and minor version numbers of your Python
543installation.</p>
544<hr class="docutils" />
545<table class="docutils footnote" frame="void" id="id22" rules="none">
546<colgroup><col class="label" /><col /></colgroup>
547<tbody valign="top">
548<tr><td class="label"><a class="fn-backref" href="#id2">[1]</a></td><td>Note that although we tested earlier versions of
549Boost.Python with Python 2.2, and we don't <em>think</em> we've done
550anything to break compatibility, this release of Boost.Python
551may not have been tested with versions of Python earlier than
5522.4, so we're not 100% sure that python 2.2 and 2.3 are
553supported.</td></tr>
554</tbody>
555</table>
556<table class="docutils footnote" frame="void" id="naming" rules="none">
557<colgroup><col class="label" /><col /></colgroup>
558<tbody valign="top">
559<tr><td class="label"><a class="fn-backref" href="#id17">[2]</a></td><td><p class="first">Information about how to identify the
560static and dynamic builds of Boost.Python:</p>
561<ul class="simple">
562<li><a class="reference external" href="../../../more/getting_started/windows.html#library-naming">on Windows</a></li>
563<li><a class="reference external" href="../../../more/getting_started/unix-variants.html#library-naming">on Unix variants</a></li>
564</ul>
565</td></tr>
566</tbody>
567</table>
568<table class="docutils footnote" frame="void" id="toolset-specific" rules="none">
569<colgroup><col class="label" /><col /></colgroup>
570<tbody valign="top">
571<tr><td class="label"><a class="fn-backref" href="#id18">[3]</a></td><td>Because of the way most *nix platforms
572share symbols among dynamically-loaded objects, I'm not certain
573that extension modules built with different compiler toolsets
574will always use different copies of the Boost.Python library
575when loaded into the same Python instance.  Not using different
576libraries could be a good thing if the compilers have compatible
577ABIs, because extension modules built with the two libraries
578would be interoperable.  Otherwise, it could spell disaster,
579since an extension module and the Boost.Python library would
580have different ideas of such things as class layout. I would
581appreciate someone doing the experiment to find out what
582happens.</td></tr>
583</tbody>
584</table>
585<table class="docutils footnote" frame="void" id="overwrite" rules="none">
586<colgroup><col class="label" /><col /></colgroup>
587<tbody valign="top">
588<tr><td class="label"><a class="fn-backref" href="#id13">[4]</a></td><td><tt class="docutils literal"><span class="pre">configure</span></tt> overwrites the existing
589<tt class="docutils literal"><span class="pre">user-config.jam</span></tt> in your home directory
590(if any) after making a backup of the old version.</td></tr>
591</tbody>
592</table>
593<table class="docutils footnote" frame="void" id="flavor" rules="none">
594<colgroup><col class="label" /><col /></colgroup>
595<tbody valign="top">
596<tr><td class="label"><a class="fn-backref" href="#id15">[5]</a></td><td>Note that the <tt class="docutils literal"><span class="pre">&lt;target-os&gt;cygwin</span></tt> feature is
597different from the <tt class="docutils literal"><span class="pre">&lt;flavor&gt;cygwin</span></tt> subfeature of the <tt class="docutils literal"><span class="pre">gcc</span></tt>
598toolset, and you might need handle both explicitly if you also
599have a MinGW GCC installed.</td></tr>
600</tbody>
601</table>
602<table class="docutils footnote" frame="void" id="home-dir" rules="none">
603<colgroup><col class="label" /><col /></colgroup>
604<tbody valign="top">
605<tr><td class="label"><a class="fn-backref" href="#id11">[6]</a></td><td><p class="first">Windows users, your home directory can be
606found by typing:</p>
607<pre class="literal-block">
608ECHO %HOMEDRIVE%%HOMEPATH%
609</pre>
610<p class="last">into a <a class="reference external" href="../../../more/getting_started/windows.html#command-prompt">command prompt</a> window.</p>
611</td></tr>
612</tbody>
613</table>
614<table class="docutils footnote" frame="void" id="get-debug-build" rules="none">
615<colgroup><col class="label" /><col /></colgroup>
616<tbody valign="top">
617<tr><td class="label"><a class="fn-backref" href="#id20">[7]</a></td><td>On Unix and similar platforms, a debugging
618python and associated libraries are built by adding
619<tt class="docutils literal"><span class="pre">--with-pydebug</span></tt> when configuring the Python build. On
620Windows, the debugging version of Python is generated by
621the &quot;Win32 Debug&quot; target of the Visual Studio project in the
622PCBuild subdirectory of a full Python source code distribution.
623You may also find</td></tr>
624</tbody>
625</table>
626</div>
627</div>
628<div class="footer">
629<hr class="footer" />
630<a class="reference external" href="./building.rst">View document source</a>.
631Generated on: 2007-07-02 13:46 UTC.
632Generated by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
633
634</div>
635</body>
636</html>
Note: See TracBrowser for help on using the repository browser.