Boost.Python构建与测试HOWTO

Boost.Python构建与测试HOWTO

（转载请注明来源于金庆的专栏）

boost文档翻译 （ http://boost.everydo.com/ ）

截止到2008.1.14：

boost文档翻译计划共有成员10名：xuwaters、金庆、yinyuanchao、felurkinda、simonyang、fatalerror99、hzjboost、alai04、farproc、jasson.wang。

目前已完成：any, array, assign, bind & mem_fn, call_traits, compressed_pair, concept_check, conversion, crc, dynamic_bitset, enable_if, foreach, format, function, in_place_factory & typed_in_place_factory, io_state_savers, iostreams, iterator, lambda, minmax, mpl, multi_index, operators, preprocessor, program_options, property_map, range, rational, ref, smart_ptr, serialization, static_assert, timer, tokenizer, tribool, tuple, type_traits, typeof, utility, value_initialized

正在进行：functional/hash, graph, math, multi_array, regex, python, spirit, string_algo, thread, variant, wave

Boost.Python Build and Test HOWTO

Boost.Python构建与测试HOWTO

Contents

• 1   Requirements
• 2   Background
• 3   No-Install Quickstart
  • 3.1   Basic Procedure
  • 3.2   In Case of Trouble
  • 3.3   In Case Everything Seemed to Work
  • 3.4   Modifying the Example Project
• 4   Installing Boost.Python on your System
• 5   Configuring Boost.Build
  • 5.1   Python Configuration Parameters
  • 5.2   Examples
• 6   Choosing a Boost.Python Library Binary
  • 6.1   The Dynamic Binary
  • 6.2   The Static Binary
• 7   #include Issues
• 8   Python Debugging Builds
• 9   Testing Boost.Python
• 10   Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users

目录

• 1   要求
• 2   背景
• 3   免安装快速入门
  • 3.1   基本过程
  • 3.2   如果遇到问题
  • 3.3   如果一切都好
  • 3.4   修改示例工程
• 4   在系统上安装Boost.Python
• 5   配置Boost.Build
  • 5.1   Python配置参数
  • 5.2   例子
• 6   选择Boost.Python二进制库
  • 6.1   动态二进制
  • 6.2   静态二进制
• 7   #include问题
• 8   Python调试版
• 9   测试Boost.Python
• 10   MinGW（及Cygwin -mno-cygwin）上GCC用户注意事项

1   Requirements

1   要求

Boost.Python requires Python 2.2¹ or newer.

Boost.Python要求Python 2.2¹ 或 更高版。

2   Background

2   背景

There are two basic models for combining C++ and Python:

• extending, in which the end-user launches the Python interpreter executable and imports Python "extension modules" written in C++. Think of taking a library written in C++ and giving it a Python interface so Python programmers can use it. From Python, these modules look just like regular Python modules.
• embedding, in which the end-user launches a program written in C++ that in turn invokes the Python interpreter as a library subroutine. Think of adding scriptability to an existing application.

组合C++和Python有两种基本模式：

• 扩展： 最终用户运行Python解译器程序，并导入用C++编写的Python“扩展模块”。 想像一个C++写的库，给它一个Python接口， 这样Python程序员就可以使用它。 从Python来看，这些模块就像是常规的Python模块。
• 内嵌： 最终用户运行C++写的程序，反过来调用Python解译器，就像调用一个库函数。 想像一下为现有的应用程序加入脚本能力。

The key distinction between extending and embedding is the location of the C++ main() function: in the Python interpreter executable, or in some other program, respectively. Note that even when embedding Python in another program, extension modules are often the best way to make C/C++ functionality accessible to Python code, so the use of extension modules is really at the heart of both models.

扩展和内嵌的关键性区别是，C++ main() 函数的位置是在Python解译器程序中， 还是在其他程序中？ 注意，即使是在程序中内嵌Python， 扩展模块往往是Python代码利用C/C++功能最好的方式， 所以，这两种模式实际上是以扩展模块的使用为中心的。

Except in rare cases, extension modules are built as dynamically-loaded libraries with a single entry point, which means you can change them without rebuilding either the other extension modules or the executable containing main().

除了极少数情况， 扩展模块是按具有单一入口点的动态库构建的， 这意味着， 你可以修改它们， 而不必重建其它扩展模块 或包含 main() 的执行程序。

3   No-Install Quickstart

3   免安装快速入门

There is no need to "install Boost" in order to get started using Boost.Python. These instructions use Boost.Build projects, which will build those binaries as soon as they're needed. Your first tests may take a little longer while you wait for Boost.Python to build, but doing things this way will save you from worrying about build intricacies like which library binaries to use for a specific compiler configuration and figuring out the right compiler options to use yourself.

使用Boost.Python不需要“安装Boost”。 这里的教程利用了 Boost.Build 项目， 它会在需要时自动构建那些二进制库。 你的第一个测试，可能需要较长的时间， 你需要等待Boost.Python的构建， 但这样做，让你不必担忧错综复杂的构建， 如，某个特定编译器配置该使用哪个二进制库， 也让你免于自己设置编译器选项。

Note

注

Of course it's possible to use other build systems to build Boost.Python and its extensions, but they are not officially supported by Boost. Moreover 99% of all "I can't build Boost.Python" problems come from trying to use another build system without first following these instructions.

当然，也可以使用其他的编译系统， 来构建Boost.Python及其扩展， 但它们不是Boost正式支持的。 所有“我无法编译Boost.Python”的问题， 99%以上是因为试图使用另一种编译系统， 而没有先按这个教程做。

If you want to use another system anyway, we suggest that you follow these instructions, and then invoke bjam with the

-a -ofilename 

options to dump the build commands it executes to a file, so you can see what your alternate build system needs to do.

如果你想使用另一个系统， 我们建议你先遵循这些指示， 然后用以下参数调用 bjam，

-a -ofilename 

来输出它对文件执行的构建命令， 这样你就可以看到你的编译系统需要做些什么。

3.1   Basic Procedure

3.1   基本过程

1. Get Boost; see sections 1 and 2 [Unix/Linux, Windows] of the Boost Getting Started Guide.

   获取Boost； 见Boost入门指南 第1和第2节[Unix/Linux， Windows]。

2. Get the bjam build driver. See section 5 [Unix/Linux, Windows] of the Boost Getting Started Guide.

   获取bjam构建驱动器。 见Boost 入门指门 第5节[Unix/Linux， Windows]。

3. cd into the libs/python/example/quickstart/ directory of your Boost installation, which contains a small example project.

   cd到Boost安装目录下的libs/python/example/quickstart/， 那里有个小的示例工程。

4. Invoke bjam. Replace the "stage" argument from the example invocation from section 5 of the Getting Started Guide with "test," to build all the test targets. Also add the argument "--verbose-test" to see the output generated by the tests when they are run.

   调用bjam。 将入门指南 第5节例示的调用命令中的 “stage”参数 替换为“test”， 来构建所有测试目标。 同时添加参数 “--verbose-test” 来查看测试运行时生成的输出。

   On Windows, your bjam invocation might look something like:

   在Windows上，你的 bjam 调用可能像这样：

   C:/boost_1_34_0/…/quickstart> bjam toolset=msvc --verbose-test test 

   and on Unix variants, perhaps,

   而在各种Unix上，可能是：

   ~/boost_1_34_0/…/quickstart$ bjam toolset=gcc --verbose-test test 

Note to Windows Users

Windows用户注意

For the sake of concision, the rest of this guide will use unix-style forward slashes in pathnames instead of the backslashes with which you may be more familiar. The forward slashes should work everywhere except in Command Prompt windows, where you should use backslashes.

为求简洁，本指南的其余部分将在路径中使用unix风格的斜杠， 而不是你可能更熟悉的反斜杠。 斜杠应该到处可用，除了 命令提示符 窗口，在那里您应该使用反斜杠。

If you followed this procedure successfully, you will have built an extension module called extending and tested it by running a Python script called test_extending.py. You will also have built and run a simple application called embedding that embeds python.

如果你能成功地遵循这个过程， 你将构建出一个扩展模块， 名为extending， 并运行一个名为 test_extending.py 的Python脚本测试它。 你也将构建并运行一个内嵌python的简单应用程序， 名为embedding。

3.2   In Case of Trouble

3.2   如果遇到问题

If you're seeing lots of compiler and/or linker error messages, it's probably because Boost.Build is having trouble finding your Python installation. You might want to pass the --debug-configuration option to bjam the first few times you invoke it, to make sure that Boost.Build is correctly locating all the parts of your Python installation. If it isn't, consider Configuring Boost.Build as detailed below.

如果你见到大量编译或连接的错误信息， 那可能是因为Boost.Build无法找到你的Python安装。 你也许要在最初几次调用bjam时， 传入--debug-configuration参数， 以确保Boost.Build正确定位了所有Python组件。 如果不是，请考虑 配置Boost.Build。

If you're still having trouble, Someone on one of the following mailing lists may be able to help:

如果仍有问题，请向以下邮件列表寻求帮助：

• The Boost.Build mailing list for issues related to Boost.Build
• The Python C++ Sig for issues specifically related to Boost.Python

• Boost.Build 邮件列表，Boost.Build相关问题
• Python C++ Sig， Boost.Python相关的专门问题

3.3   In Case Everything Seemed to Work

3.3   如果一切都好

Rejoice! If you're new to Boost.Python, at this point it might be a good idea to ignore build issues for a while and concentrate on learning the library by going through the tutorial and perhaps some of the reference documentation, trying out what you've learned about the API by modifying the quickstart project.

恭喜！ 如果您是Boost.Python新手， 此时，最好暂时不理会构建问题， 而是集中精力去学习库， 尽快学完教程， 然后可能是参考文档， 同时通过修改快速入门工程， 试用你所学到的API。

3.4   Modifying the Example Project

3.4   修改示例工程

If you're content to keep your extension module forever in one source file called extending.cpp, inside your Boost distribution, and import it forever as extending, then you can stop here. However, it's likely that you will want to make a few changes. There are a few things you can do without having to learn Boost.Build in depth.

如果你满足于此， 扩展模块的源文件永远是 extending.cpp， 位于Boost发布目录中， 并永远按extending导入， 那么你就可以到此为止。 不过很可能是，你会想作一些变动。 有许多事你可以做，而无须深入学习 Boost.Build。

The project you just built is specified in two files in the current directory: boost-build.jam, which tells bjam where it can find the interpreted code of the Boost build system, and Jamroot, which describes the targets you just built. These files are heavily commented, so they should be easy to modify. Take care, however, to preserve whitespace. Punctuation such as ; will not be recognized as intended by bjam if it is not surrounded by whitespace.

你刚刚构建的工程， 是由当前目录下的两个文件详细说明的： boost-build.jam （它告诉bjam， 哪里可以找到Boost编译系统的解释代码）， 和Jamroot （它描述了你刚刚构建的目标）。 这些文件具有详细的注释，所以它们应该很容易修改。 不过小心，要保留空白字符。 如;这样的标点符号， 如果周围没有空白字符， bjam将无法识别。

Relocate the Project

工程移位

You'll probably want to copy this project elsewhere so you can change it without modifying your Boost distribution. To do that, simply

你可能想把该工程复制到其他位置， 这样你就可以修改它， 而不必在Boost发布目录中更改。 要做到这一点，只需

1. copy the entire libs/python/example/quickstart/ directory into a new directory.
2. In the new copies of boost-build.jam and Jamroot, locate the relative path near the top of the file that is clearly marked by a comment, and edit that path so that it refers to the same directory your Boost distribution as it referred to when the file was in its original location in the libs/python/example/quickstart/ directory.

1. 复制整个libs/python/example/quickstart/ 目录到一个新的目录。
2. 在新的boost-build.jam 和Jamroot 副本中， 靠近文件顶部， 找到由一条注释清楚标注的相对路径， 然后编辑这个路径， 让它指向Boost发布目录， 与它原来（当文件在libs/python/example/quickstart/ 目录时）所指目录相同。

For example, if you moved the project from /home/dave/boost_1_34_0/libs/python/example/quickstart to /home/dave/my-project, you could change the first path in boost-build.jam from

例如，如果你的工程从 /home/dave/boost_1_34_0/libs/python/example/quickstart 移至/home/dave/my-project， 你可以更改 boost-build.jam 中的第一个路径，从

../../../../tools/build/v2 

to

改为

/home/dave/boost_1_34_0/tools/build/v2 

and change the first path in Jamroot from

并且，将Jamroot 中的第一个路径从

../../../.. 

to

改为

/home/dave/boost_1_34_0 

Add New or Change Names of Existing Source Files

添加新的源文件或更改源文件名

The names of additional source files involved in building your extension module or embedding application can be listed in Jamroot right alongside extending.cpp or embedding.cpp respectively. Just be sure to leave whitespace around each filename:

构建扩展模块或内嵌应用程序时， 涉及的其他源文件的名字， 可以在Jamroot中列出， 分别列于extending.cpp 或embedding.cpp旁边。 只是每个文件名周围，务必留下空白字符：

… file1.cpp file2.cpp file3.cpp …

Naturally, if you want to change the name of a source file you can tell Boost.Build about it by editing the name in Jamroot.

当然，如果你想要更改源文件名， 你可以编辑 Jamroot 中的文件名，来告诉Boost.Build。

Change the Name of your Extension Module

更改扩展模块的名字

The name of the extension module is determined by two things:

扩展模块的名字，由两个地方决定：

1. the name in Jamroot immediately following python-extension, and
2. the name passed to BOOST_PYTHON_MODULE in extending.cpp.

1. 在Jamroot 中紧跟python-extension 的名字， 和
2. 在extending.cpp中 传给BOOST_PYTHON_MODULE 的名字。

To change the name of the extension module from extending to hello, you'd edit Jamroot, changing

要将扩展模块名从extending 改为hello， 你需要编辑Jamroot，将

python-extension extending : extending.cpp ; 

to

改为

python-extension hello : extending.cpp ; 

and you'd edit extending.cpp, changing

还需要编辑extending.cpp，将

BOOST_PYTHON_MODULE(extending) 

to

改为

BOOST_PYTHON_MODULE(hello) 

4   Installing Boost.Python on your System

4   在系统上安装Boost.Python

Since Boost.Python is a separately-compiled (as opposed to header-only) library, its user relies on the services of a Boost.Python library binary.

由于Boost.Python是一个单独编译的库（有别于纯头文件库）， 它的用户需要依赖Boost.Python二进制库的服务。

If you need a regular installation of the Boost.Python library binaries on your system, the Boost Getting Started Guide will walk you through the steps of creating one. If building binaries from source, you might want to supply the --with-python argument to bjam (or the --with-libraries=python argument to configure), so only the Boost.Python binary will be built, rather than all the Boost binaries.

如果你需要在系统上安装一个常规的Boost.Python二进制库， Boost入门指南将带你一步一步创建它。 如果从源文件构建二进制， 你也许要向bjam 提供--with-python 参数（或向configure 提供--with-libraries=python 参数）， 这样就会仅仅构建Boost.Python二进制， 而不是所有的Boost二进制。

5   Configuring Boost.Build

5   配置Boost.Build

As described in the Boost.Build reference manual, a file called user-config.jam in your home directory⁶ is used to specify the tools and libraries available to the build system. You may need to create or edit user-config.jam to tell Boost.Build how to invoke Python, #include its headers, and link with its libraries.

正如Boost.Build参考手册所述， 在你的主目录⁶下， 有一个user-config.jam文件， 用来指定编译系统可用的工具和库。 您可能需要创建或编辑user-config.jam， 来告诉Boost.Build如何调用Python， #include 它的头文件，并链接它的库。

Users of Unix-Variant OSes

类Unix OS用户

If you are using a unix-variant OS and you ran Boost's configure script, it may have generated a user-config.jam for you.⁴ If your configure/make sequence was successful and Boost.Python binaries were built, your user-config.jam file is probably already correct.

如果你使用的是类Unix操作系统， 并且你运行了Boost configure 脚本， 它可能已经为你生成了一个user-config.jam⁴。 如果你configure/make 就能成功构建Boost.Python， 你的user-config.jam 文件可能已经是正确的了。

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 user-config.jam (and you don't specify --without-python on the Boost.Build command line), Boost.Build will automatically execute the equivalent of

如果你的平台有一个相当“标准”的python安装， 你可能不需要对它做特别描述。 如果你没有在user-config.jam 中配置python（并且没有在Boost.Build命令行中指定 --without-python）， Boost.Build将自动执行以下等效语句

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 user-config.jam file with at least the minimal incantation above.

这会让它在最有可能的地方自动寻找Python。 不过，这只会发生在当使用Boost.Python项目文件时 （例如，当被另一个项目引用时，如 快速入门所示方法）。 反之，如果你链接单独编译的Boost.Python二进制， 你应该建立一个 user-config.jam文件， 至少包含以上最少量的咒语。

5.1   Python Configuration Parameters

5.1   Python配置参数

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 parameters to using python.

如果你安装了多个Python， 或Python以一个不寻常的方式安装， 你可能要向using python 提供下列部分或全部可选参数。

version

the version of Python to use. Should be in Major.Minor format, for example, 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 required.

使用的Python的版本。 格式为“主要版本号.次要版本号”， 例如 2.3。 不包括子次版本号（即 不是 2.5.1）。 如果你安装了多个版本的Python， 版本号通常是唯一要求的配置参数。

cmd-or-prefix

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.

最好是一个调用Python解释器的命令。 也可以是，Python库和头文件的安装前缀。 仅当没有合适的Python可执行程序时， 才使用第二种方式。

includes

the #include paths for Python headers. Normally the correct path(s) will be automatically deduced from version and/or cmd-or-prefix.

Python头文件的 #include路径。 通常，正确的路径将从 version和 cmd-or-prefix 自动推断。

libraries

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 version and/or cmd-or-prefix.

Python二进制库的路径。 在MacOS/Darwin上，你还可以传入Python框架的路径。 通常，正确的路径将从 version和 cmd-or-prefix 自动推断。

condition

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.

如果要指定，应该是一组Boost.Build属性， 当Boost.Build选择使用一个Python配置时， 用于改写默认的构建配置。 详情见下面例子。

extension-suffix

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 feature. However, at least one Linux distribution (Ubuntu Feisty Fawn) has a specially configured python-dbg package that claims to use such a suffix.

一个字符串，用来附加到扩展模块名上（在真实的文件扩展名之前）。 你几乎肯定不需要用到这个。 通常这个后缀只用于针对Windows的Python调试版， 并且，它会基于 特性的值自动设定。 不过，至少有一个Linux发行版（Ubuntu Feisty Fawn）， 有一个特别配置的 python-dbg 包， 声称使用了这样的后缀。

5.2   Examples

5.2   例子

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:

  如果你同时安装了python 2.5和python 2.4， user-config.jam可能包含：

  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 python=2.4 to the bjam command line.

  第一个配置的版本（2.5）将成为默认值。 如果要使用python 2.4构建， 请在bjam命令行中添加 python=2.4。

• If you have python installed in an unusual location, you might supply the path to the interpreter in the cmd-or-prefix parameter:

  如果你把python安装在一个不寻常的位置， 你可以在cmd-or-prefix参数中 提供解释器的路径：

  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 condition parameter:

  如果一个特定工具集使用了一个单独构建的Python， 你可以在condition 参数中提供该工具集。

  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
        : 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:

  如果你下载了Python源码并且在Windows上自己构建了python和 python调试版， 你可能会看到：

  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
    : 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 cygwin in the condition parameter for the cygwin python installation:

  你可以设置user-config.jam， 让Windows上的bjam能够构建和测试两个版本的python扩展， 既有Windows版， 也有Cygwin版。 只需在condition参数中， 为cygwin的python安装 传入cygwin：

  # windows installation
  using python ;
  
  # cygwin installation
  using python : : c://cygwin//bin//python2.5 : : : cygwin ;
   

  when you put target-os=cygwin in your build request, it should build with the cygwin version of python:⁵

  当你在构建请求中加入target-os=cygwin， 它就应该使用cygwin版本的python进行构建：⁵

  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.

  另一种方式应该也行 （使用Cygwin上的bjam， 以windows python为目标）， 但在本文写作之时， Boost.Build的工具集对那种构建方式的支持好像有问题。

• 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:

  注意，在 Boost.Build目前选择不同目标的方式下， 可能你的编译请求必须非常明确。 举例来说，如有：

  using python : 2.5 ; # a regular windows build
  using python : 2.4 : : : : cygwin ; 

  building with

  以

  bjam target-os=cygwin 

  will yield an error. Instead, you'll need to write:

  构建会产生一个错误。你需要这样写才行：

  bjam target-os=cygwin/python=2.4 

6   Choosing a Boost.Python Library Binary

6   选择Boost.Python二进制库

If—instead of letting Boost.Build construct and link with the right libraries automatically—you choose to use a pre-built Boost.Python library, you'll need to think about which one to link with. The Boost.Python binary comes in both static and dynamic flavors. Take care to choose the right flavor for your application.²

如果不是任由Boost.Build自动构建和链接正确的库， 而是选择使用预建的Boost.Python库， 你需要考虑一下链接哪个库。 Boost.Python二进制库同时具有静态和动态库。 请为您的应用小心选择正确的库。²

6.1   The Dynamic Binary

6.1   动态二进制

The dynamic library is the safest and most-versatile choice:

动态库是最安全和最通用的选择：

• A single copy of the library code is used by all extension modules built with a given toolset.³
• The library contains a type conversion registry. Because one registry is shared among all extension modules, instances of a class exposed to Python in one dynamically-loaded extension module can be passed to functions exposed in another such module.

• 用特定工具集构建的所有扩展模块， 都使用同一份库代码。³
• 库包含一个类型转换注册表。 因为所有扩展模块共享一个注册表，所以， 在一个动态装载的扩展模块中， 导出到Python的类实例， 可以传给另一个动态模块中导出的函数。

6.2   The Static Binary

6.2   静态二进制

It might be appropriate to use the static Boost.Python library in any of the following cases:

下列任一情况下，可能适合使用静态的Boost.Python库：

• You are extending python and the types exposed in your dynamically-loaded extension module don't need to be used by any other Boost.Python extension modules, and you don't care if the core library code is duplicated among them.
• You are embedding python in your application and either:
  • You are targeting a Unix variant OS other than MacOS or AIX, where the dynamically-loaded extension modules can "see" the Boost.Python library symbols that are part of the executable.
  • Or, you have statically linked some Boost.Python extension modules into your application and you don't care if any dynamically-loaded Boost.Python extension modules are able to use the types exposed by your statically-linked extension modules (and vice-versa).

• 你是在扩展Python， 并且，你动态加载的扩展模块中导出的类型， 不需要被其他Boost.Python扩展模块使用， 你也不关心核心库代码是否在它们中间重复。
• 你是在应用程序中内嵌 Python，并且：
  • 你的目标是MacOS或AIX以外的类Unix OS， 在那里，动态加载的扩展模块， 可以“看见”可执行文件中Boost.Python库的符号。
  • 或者，你已经静态链接了一些Boost.Python扩展模块到你的应用程序， 并且你不关心 动态加载的Boost.Python扩展模块， 是否能够使用你静态链接的扩展模块所导出的类型（反之亦然）。

7   #include Issues

7   #include问题

1. If you should ever have occasion to #include "python.h" directly in a translation unit of a program using Boost.Python, use #include "boost/python/detail/wrap_python.hpp" instead. It handles several issues necessary for use with Boost.Python, one of which is mentioned in the next section.
2. Be sure not to #include any system headers before wrap_python.hpp. This restriction is actually imposed by Python, or more properly, by Python's interaction with your operating system. See http://docs.python.org/ext/simpleExample.html for details.

1. 在使用Boost.Python的程序中， 如果你需要在某个翻译单元中直接 #include "python.h"， 请改为使用#include "boost/python/detail/wrap_python.hpp"。 它处理了Boost.Python使用中几个必要问题， 其中一个将在接下来的一节中提到。
2. 在wrap_python.hpp之前， 千万不要#include 任何系统头文件。 这一限制实际上是由Python强加的， 更严格地说， 是由Python与你的操作系统相互作用造成的。 详见http://docs.python.org/ext/simpleExample.html。

8   Python Debugging Builds

8   Python调试版

Python can be built in a special "python debugging" configuration that adds extra checks and instrumentation that can be very useful for developers of extension modules. The data structures used by the debugging configuration contain additional members, so a Python executable built with python debugging enabled cannot be used with an extension module or library compiled without it, and vice-versa.

Python可以用一个特殊的配置，“Python调试”，进行构建， 它增加了额外的检查和测试， 对扩展模块的开发者非常有用。 调试配置所使用的数据结构， 包含了附加的成员， 因此， 用python调试模式构建的Python可执行程序， 不能使用非调试模式编译的扩展模块或库， 反之亦然。

Since pre-built "python debugging" versions of the Python executable and libraries are not supplied with most distributions of Python,⁷ and we didn't want to force our users to build them, Boost.Build does not automatically enable python debugging in its debug build variant (which is the default). Instead there is a special build property called python-debugging that, when used as a build property, will define the right preprocessor symbols and select the right libraries to link with.

由于在大多数Python发行版中， 没有提供预建的“python调试”版的Python可执行程序和库 ⁷， 而且我们不想强迫我们的用户去构建它们， 所以，在Boost.Python的debug版中 （默认是debug版）， 没有自动打开python调试模式， 作为替代，有一个特别的构建属性， 称为python-debugging， 使用该构建属性时， 会定义正确的预处理符号，并选择正确的库进行链接。

On unix-variant platforms, the debugging versions of Python's data structures will only be used if the symbol Py_DEBUG is defined. On many windows compilers, when extension modules are built with the preprocessor symbol _DEBUG, Python defaults to force linking with a special debugging version of the Python DLL. Since that symbol is very commonly used even when Python is not present, Boost.Python temporarily undefines _DEBUG when Python.h is #included from boost/python/detail/wrap_python.hpp - unless BOOST_DEBUG_PYTHON is defined. The upshot is that if you want "python debugging" and you aren't using Boost.Build, you should make sure BOOST_DEBUG_PYTHON is defined, or python debugging will be suppressed.

在类Unix平台上， 仅当定义了Py_DEBUG符号时， 才会使用调试版Python的数据结构。 在许多Windows编译器上， 当扩展模块用预处理符号 _DEBUG 构建时， Python默认会强制链接一个特殊的，调试版本的Python DLL。 由于这个符号很常用（甚至没有Python时），所以， 在boost/python/detail/wrap_python.hpp中包含Python.h时， Boost.Python暂时取消了_DEBUG定义 ——除非定义了BOOST_DEBUG_PYTHON。 其结果是，如果你想要“Python调试”， 并且你没有用Boost.Build， 你务必定义BOOST_DEBUG_PYTHON， 不然python调试会被禁用。

9   Testing Boost.Python

9   测试Boost.Python

To run the full test suite for Boost.Python, invoke bjam in the libs/python/test subdirectory of your Boost distribution.

在Boost的 libs/python/test子目录下， 调用bjam， 以运行Boost.Python完整的测试包。

10   Notes for MinGW (and Cygwin with -mno-cygwin) GCC Users

10   MinGW（及Cygwin -mno-cygwin）上GCC用户注意事项

If you are using a version of Python prior to 2.4.1 with a MinGW prior to 3.0.0 (with binutils-2.13.90-20030111-1), you will need to create a MinGW-compatible version of the Python library; the one shipped with Python will only work with a Microsoft-compatible linker. Follow the instructions in the "Non-Microsoft" section of the "building Extensions: Tips And Tricks" chapter in Installing Python Modules to create libpythonXX.a, where XX corresponds to the major and minor version numbers of your Python installation.

如果你正在使用Python 2.4.1， MinGW 3.0.0（和binutils-2.13.90-20030111-1）之前的版本， 您将需要创建一个与MinGW兼容的Python库； Python发行随带的库只能用于微软兼容的连接器。 请转到安装Python模块， “构建扩展：提示和技巧”一章， “非微软”一节， 按照指示来创建libpythonXX.a， 其中XX 为你的Python安装的主要和次要版本号。

---

[1]

Note that although we tested earlier versions of Boost.Python with Python 2.2, and we don't think we've done anything to break compatibility, this release of Boost.Python may not have been tested with versions of Python earlier than 2.4, so we're not 100% sure that python 2.2 and 2.3 are supported. 注意，尽管我们在Python 2.2上测试过Boost.Python的早期版本， 并且我们认为我们没有破坏兼容性， 但本次发行的Boost.Python可能没有在Python 2.4以前的版本上测试过， 所以我们不是100%的肯定能支持python 2.2和2.3。

[2]	Information about how to identify the static and dynamic builds of Boost.Python: 有关如何确定Boost.Python的静态版和动态版： on Windows on Unix variants 在Windows上 在各种Unix上

[3]

Because of the way most *nix platforms share symbols among dynamically-loaded objects, I'm not certain that extension modules built with different compiler toolsets will always use different copies of the Boost.Python library when loaded into the same Python instance. Not using different libraries could be a good thing if the compilers have compatible ABIs, because extension modules built with the two libraries would be interoperable. Otherwise, it could spell disaster, since an extension module and the Boost.Python library would have different ideas of such things as class layout. I would appreciate someone doing the experiment to find out what happens. 在大多数*nix平台上， 在动态装载的对象之间， 由于符号共享方式的关系， 用不同编译工具构建的扩展模块， 当加载到同一Python实例时， 我不能肯定， 是否总是使用不同的Boost.Python库。 如果编译器都具有兼容的ABI， 那么，使用相同的库将是一件好事， 因为用两个库构建的两个扩展模块将可以互操作。 否则将带来灾难， 因为扩展模块和Boost.Python库， 将对如类布局之类的事情， 有不同的想法。 如果有人做实验，以了解会发生什么，我将不胜感激。

[4]	configure overwrites the existing user-config.jam in your home directory (if any) after making a backup of the old version. configure会覆盖主目录下现有的 user-config.jam（如果存在旧版本，会先备份它）。

[5]	Note that the cygwin feature is different from the cygwin subfeature of the gcc toolset, and you might need handle both explicitly if you also have a MinGW GCC installed. 注意，特性cygwin 有别于gcc 工具集的子特性 cygwin， 如果你同时也安装了MinGW GCC， 你可能需要明确处理这两个特性。

[6]	Windows users, your home directory can be found by typing: ECHO %HOMEDRIVE%%HOMEPATH% into a command prompt window. Windows用户可以在 命令提示符窗口中， 键入以下命令显示自己的主目录： ECHO %HOMEDRIVE%%HOMEPATH%

[7]

On Unix and similar platforms, a debugging python and associated libraries are built by adding --with-pydebug when configuring the Python build. On Windows, the debugging version of Python is generated by the "Win32 Debug" target of the Visual Studio project in the PCBuild subdirectory of a full Python source code distribution. You may also find 在UNIX和类似平台上， 在配置Python构建时 添加--with-pydebug， 就可以构建调试版Python及相关库。 在Windows上，调试版本的Python， 是在Visual Studio项目中， 由“Win32 Debug”目标产生， 该项目文件位于 Python源代码发行目录的PCBuild子目录。 你也可以找到

---

View document source. Generated on: 2007-07-02 13:46 UTC. Generated by Docutils from reStructuredText source.
翻译： 金庆 2008.1.17