diff --git a/doc/building.html b/doc/building.html
index cdca6b97..d76a708c 100644
--- a/doc/building.html
+++ b/doc/building.html
@@ -1,222 +1,294 @@
-
+
+
+
+
+
- Building an Extension Module
+ Boost.Python - Building and Testing
+
-
-
Building an
- Extension Module
+
+
+
+
+
+
-
Building Boost.Python
+
+
Boost.Python
-
Every Boost.Python extension module must be linked with the
- boost_python shared library. To build
- boost_python, use Boost.Build in the
- usual way from the libs/python/build subdirectory
- of your boost installation (if you have already built boost from
- the top level this may have no effect, since the work is already
- done).
+
Building and Testing
+
+
+
+
-
Configuration
- You may need to configure the following variables to point Boost.Build at your Python installation:
+
Every Boost.Python extension module must be linked with the
+ boost_python shared library. To build
+ boost_python, use Boost.Build in the usual way from
+ the libs/python/build subdirectory of your boost
+ installation (if you have already built boost from the top level this may
+ have no effect, since the work is already done).
+ You may need to configure the following variables to point Boost.Build at
+ your Python installation:
+
+
+
+
Variable Name
+
+
Semantics
+
+
Default
+
+
Notes
+
+
+
+
PYTHON_ROOT
+
+
The root directory of your Python installation
-
-
Variable Name
Semantics
Default
Notes
-
-
PYTHON_ROOT
-
The root directory of your Python installation
Windows: c:/tools/python
- Unix: /usr/local
-
On Unix, this is the --with-prefix= directory
- used to configure Python
+ Unix: /usr/local
+
+
On Unix, this is the --with-prefix= directory used
+ to configure Python
+
+
+
+
PYTHON_VERSION
+
+
The The 2-part python Major.Minor version number
+
+
2.2
-
-
PYTHON_VERSION
-
The The 2-part python Major.Minor version number
-
Windows: 2.1
- Unix: 1.5
Be sure not to include a third number, e.g. not
- "2.2.1", even if that's the version you
- have.
+ "2.2.1", even if that's the version you have.
+
-
-
PYTHON_INCLUDES
-
path to Python #include directories
-
Autoconfigured from PYTHON_ROOT
+
+
PYTHON_INCLUDES
-
-
PYTHON_LIB_PATH
-
path to Python library object.
-
Autoconfigured from PYTHON_ROOT
+
path to Python #include directories
-
-
PYTHON_STDLIB_PATH
-
path to Python standard library modules
-
Autoconfigured from PYTHON_ROOT
+
Autoconfigured from PYTHON_ROOT
+
+
+
+
PYTHON_LIB_PATH
+
+
path to Python library object.
+
+
Autoconfigured from PYTHON_ROOT
+
+
+
+
PYTHON_STDLIB_PATH
+
+
path to Python standard library modules
+
+
Autoconfigured from PYTHON_ROOT
+
+
+
+
CYGWIN_ROOT
+
+
path to the user's Cygwin installation
-
-
CYGWIN_ROOT
-
path to the user's Cygwin installation
-
Cygwin only. This and the following two settings are
- useful when building with multiple toolsets on Windows, since
- Cygwin requires a different build of Python.
+
Cygwin only. This and the
+ following two settings are useful when building with multiple
+ toolsets on Windows, since Cygwin requires a different build of
+ Python.
The build process will create a
- libs/python/build/bin-stage subdirectory of the
- boost root (or of $(ALL_LOCATE_TARGET),
- if you have set that variable), containing the built
- libraries. The libraries are actually built to unique
- directories for each toolset and variant elsewhere in the
- filesystem, and copied to the
- bin-stage directory as a convenience, so if you
- build with multiple toolsets at once, the product of later
- toolsets will overwrite that of earlier toolsets in
- bin-stage.
+
$(CYGWIN_ROOT)/usr/local
-
Testing
-
To build and test Boost.Python from within the
- libs/python/build directory, invoke
-
The build process will create a
+ libs/python/build/bin-stage subdirectory of the boost root
+ (or of $(ALL_LOCATE_TARGET), if you have set that variable),
+ containing the built libraries. The libraries are actually built to
+ unique directories for each toolset and variant elsewhere in the
+ filesystem, and copied to the bin-stage directory as a
+ convenience, so if you build with multiple toolsets at once, the product
+ of later toolsets will overwrite that of earlier toolsets in
+ bin-stage.
-This will
-update all of the Boost.Python v1 test and example targets. The tests
-are relatively quiet by default. To get more-verbose output, you might try
-
+
+ This will update all of the Boost.Python v1 test and example targets. The
+ tests are relatively quiet by default. To get more-verbose output, you
+ might try
+
+
-bjam -sTOOLS=toolset -sPYTHON_TEST_ARGS=-v test
+bjam -sTOOLS=toolset -sPYTHON_TEST_ARGS=-v test
-
-which will print each test's Python code with the expected output as
-it passes.
+
+ which will print each test's Python code with the expected output as it
+ passes.
-
+ Though there are other approaches, the easiest way to build an extension
+ module using Boost.Python is with Boost.Build. Until Boost.Build v2 is
+ released, cross-project build dependencies are not supported, so it works
+ most smoothly if you add a new subproject to your boost installation. The
+ libs/python/example subdirectory of your boost installation
+ contains a minimal example (along with many extra sources). To copy the
+ example subproject:
- Though there are other approaches, the easiest way to build an
- extension module using Boost.Python is with Boost.Build. Until
- Boost.Build v2 is released, cross-project build dependencies are
- not supported, so it works most smoothly if you add a new
- subproject to your boost installation. The
- libs/python/example subdirectory of your boost
- installation contains a minimal example (along with many extra
- sources). To copy the example subproject:
-
-
+
Create a new subdirectory in, libs/python, say
- libs/python/my_project.
+ libs/python/my_project.
Edit the Jamfile as appropriate for your project. You'll
- want to change the "subproject" rule
- invocation at the top, and the names of some of the source files
- and/or targets.
+
Edit the Jamfile as appropriate for your project. You'll want to
+ change the "subproject" rule invocation at the top, and
+ the names of some of the source files and/or targets.
+
+ If you can't modify or copy your boost installation, the alternative is
+ to create your own Boost.Build project. A similar example you can use as
+ a starting point is available in this archive. You'll need to edit the
+ Jamfile and Jamrules files, depending on the relative location of your
+ Boost installation and the new project. Note that automatic testing of
+ extension modules is not available in this configuration.
-
+
+ Three variant
+ configurations of all python-related targets are supported, and can be
+ selected by setting the BUILD
+ variable:
- If you can't modify or copy your boost installation, the
- alternative is to create your own Boost.Build project. A similar
- example you can use as a starting point is available in this archive. You'll
- need to edit the Jamfile and Jamrules files, depending on the
- relative location of your Boost installation and the new
- project. Note that automatic testing of extension modules is not
- available in this configuration.
+
- Three variant
- configurations of all python-related targets are supported, and
- can be selected by setting the BUILD
- variable:
+
debug-python (no optimization, -D_DEBUG
+ -DBOOST_DEBUG_PYTHON)
+
-
-
release (optimization, -DNDEBUG)
+
The first two variants of the boost_python library are
+ built by default, and are compatible with the default Python
+ distribution. The debug-python variant corresponds to a
+ specially-built debugging version of Python. On Unix platforms, this
+ python is 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 PCBuild.dsw
+ Visual C++ 6.0 project in the PCBuild subdirectory of your
+ Python distribution. Extension modules built with Python debugging
+ enabled are not link-compatible with a non-debug build of Python.
+ Since few people actually have a debug build of Python (it doesn't come
+ with the standard distribution), the normal debug variant
+ builds modules which are compatible with ordinary Python.
-
debug (no optimization -D_DEBUG)
+
On many windows compilers, when extension modules are built with
+ -D_DEBUG, Python defaults to force linking with a special
+ debugging version of the Python DLL. Since this debug DLL isn't supplied
+ with the default Python installation for Windows, Boost.Python uses
+ boost/python/detail/wrap_python.hpp
+ to temporarily undefine _DEBUG when Python.h is
+ #included - unless BOOST_DEBUG_PYTHON is
+ defined.
-
debug-python (no optimization, -D_DEBUG
- -DBOOST_DEBUG_PYTHON)
-
+
If you want the extra runtime checks available with the debugging
+ version of the library, #define BOOST_DEBUG_PYTHON to re-enable
+ python debuggin, and link with the debug-python variant of
+ boost_python.
-
The first two variants of the boost_python
- library are built by default, and are compatible with the
- default Python distribution. The debug-python
- variant corresponds to a specially-built debugging version of
- Python. On Unix platforms, this python is 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
- PCBuild.dsw Visual C++ 6.0 project in the
- PCBuild subdirectory of your Python distribution.
+
If you do not #define BOOST_DEBUG_PYTHON, be sure that any
+ source files in your extension module #include <boost/python/detail/wrap_python.hpp>
+ instead of the usual Python.h, or you will have link
+ incompatibilities.
+
+
- Extension modules built with Python debugging enabled are not
- link-compatible with a non-debug build of Python. Since few
- people actually have a debug build of Python (it doesn't come
- with the standard distribution), the normal
- debug variant builds modules which are compatible
- with ordinary Python.
+
On many windows compilers, when extension modules are built
- with
- -D_DEBUG, Python defaults to force linking with a
- special debugging version of the Python DLL. Since this debug DLL
- isn't supplied with the default Python installation for Windows,
- Boost.Python uses boost/python/detail/wrap_python.hpp
- to temporarily undefine _DEBUG when Python.h is
- #included - unless BOOST_DEBUG_PYTHON is defined.
-
-
If you want the extra runtime checks available with the
- debugging version of the library, #define
- BOOST_DEBUG_PYTHON to re-enable python debuggin, and link
- with the debug-python variant of
- boost_python.
-
-
If you do not #define BOOST_DEBUG_PYTHON, be sure that
- any source files in your extension module #include <boost/python/detail/wrap_python.hpp>
- instead of the usual Python.h, or you will have link
- incompatibilities.
-
-
- Use the Boost Python Library to quickly and easily export a C++ library to Python such that the Python interface is
- very similar to the C++ interface. It is designed to be minimally
- intrusive on your C++ design. In most cases, you should not have to alter
- your C++ classes in any way in order to use them with Boost.Python. The system
- should simply ``reflect'' your C++ classes and functions into
- Python.
+
+
+
+
+
-
+
Boost.Python
+
-
-
Note: this is the last official release of
-Boost.Python v1. Development of this version of the library has
-stopped; it will be retired soon in favor of the redesigned and
-improved version 2. A summary of the development goals is available on
-the Python C++-sig
-page, which also serves as a mailing list for users of both versions
-of the library. A preview of the v2 documentation is available here,
-and instructions for getting started with a prerelease are available
-upon request.
-
+
+
+
+
+
+
-
Supported Platforms
-
Boost.Python is known to have been tested
-against Python 2.2.1 using
-the following compilers:
+
Compaq C++ V6.2-024 for Digital UNIX (an EDG-based compiler).
- All tests pass.
- Note that the Boost.Compatibility
- library must be included (see e.g. tru64_cxx.mak in the build
- directory).
+
Silicon Graphics MIPSpro Version 7.3.1.2m (an EDG-based compiler).
- All tests pass.
- Note that the Boost.Compatibility
- library must be included (see e.g. irix_CC.mak in the build
- directory).
+
GCC 2.95.2 under MinGW and RedHat Linux 7.1.
- Compilation succeeds, but some tests fail at runtime due to
- exception handling bugs. It is therefore highly recommended
- to use GCC 3.0.4 instead.
+
-Note that pickling doesn't work with Python 2.2
-due to a core language bug. This is fixed in
-2.2.1.
+
Revised
+
+ 08 October, 2002
+
+
-
-Boost.Python has also been used with other versions of Python back to
-Python 1.5.2. It is expected that the older Python releases still work,
-but we are not regularly testing for backward compatibility.
-
-
Credits
-
-
David Abrahams originated
- and wrote most of the library, and continues to coordinate development.
-
-
Ullrich Koethe
- had independently developed a similar system. When he discovered Boost.Python,
- he generously contributed countless hours of coding and much insight into
- improving it. He is responsible for an early version of the support for function overloading and wrote the support for
- reflecting C++ inheritance
- relationships. He has helped to improve error-reporting from both
- Python and C++, and has designed an extremely easy-to-use way of
- exposing numeric operators, including
- a way to avoid explicit coercion by means of overloading.
-
-
Ralf W.
- Grosse-Kunstleve contributed pickle support
- and numerous other small improvements. He's working on a way to allow
- types exported by multiple modules to interact.
-
-
The members of the boost mailing list and the Python community
- supplied invaluable early feedback. In particular, Ron Clarke, Mark Evans,
- Anton Gluck, Chuck Ingold, Prabhu Ramachandran, and Barry Scott took the
- brave step of trying to use Boost.Python while it was still in early
- stages of development.
-
-
The development of Boost.Python wouldn't have been possible without
- the generous support of Dragon
- Systems/Lernout and Hauspie, Inc who supported its development as an
- open-source project.
-
- Documentation is a major ongoing project; assistance is greatly
- appreciated! In the meantime, useful examples of every Boost.Python feature should
- be evident in the regression test files test/comprehensive.[py/hpp/cpp]
-
-
- Questions should be directed to the Python C++ SIG.
-
-
+
+
diff --git a/doc/tutorial/doc/building_hello_world.html b/doc/tutorial/doc/building_hello_world.html
index 8595ea56..68094b60 100644
--- a/doc/tutorial/doc/building_hello_world.html
+++ b/doc/tutorial/doc/building_hello_world.html
@@ -36,26 +36,22 @@ building Boost.Python, check out:
building.html.
After this brief bjam tutorial, we should have built two DLLs:
boost_python.dll
hello.pyd
-if you are on Windows, and
-
libboost_python.so
hello.so
-if you are on Unix.
+This assumes of course that we are running on Windows.
The tutorial example can be found in the directory:
-libs/python/example/tutorial. There, you can find:
+/libs/python/example/tutorial. There, you can find:
hello.cpp
Jamfile
The hello.cpp file is our C++ hello world example. The Jamfile is a
minimalist bjam script that builds the DLLs for us.
Before anything else, you should have the bjam executable in your boost
-directory. Pre-built Boost.Jam executables are available for most
+directory. Pre-built Boost.Jam executables are available for some
platforms. For example, a pre-built Microsoft Windows bjam executable can
be downloaded
here.
The complete list of bjam pre-built executables can be found
here.
The above assumes that the Python installation is in c:/dev/tools/python
-and that we are using Python version 2.2. You'll have to tweak this path
-appropriately. Be sure not to include a third number, e.g. not "2.2.1",
-even if that's the version you have.
+and that we are using Python version 2.2. Be sure not to include a third
+number, e.g. not "2.2.1", even if that's the version you have.
Now we are ready... Be sure to cd to libs/python/example/tutorial
where the tutorial "hello.cpp" and the "Jamfile" is situated.
@@ -144,10 +139,6 @@ And so on... Finally:
If all is well, you should now have:
boost_python.dll
hello.pyd
-if you are on Windows, and
-
libboost_python.so
hello.so
-if you are on Unix.
-
boost_python.dll can be found somewhere in libs\python\build\bin
while hello.pyd can be found somewhere in
libs\python\example\tutorial\bin. After a successful build, you can just
diff --git a/doc/tutorial/doc/call_policies.html b/doc/tutorial/doc/call_policies.html
index 194097df..f0decf84 100644
--- a/doc/tutorial/doc/call_policies.html
+++ b/doc/tutorial/doc/call_policies.html
@@ -142,7 +142,7 @@ or more policies can be composed by chaining. Here's the general syntax:
Here is the list of predefined call policies. A complete reference detailing
-these can be found
+these can be found
here.
with_custodian_and_ward Ties lifetimes of the arguments
with_custodian_and_ward_postcall Ties lifetimes of the arguments and results
return_internal_reference Ties lifetime of one argument to that of result
manage_new_object Adopt a pointer and hold the instance
diff --git a/doc/tutorial/doc/class_data_members.html b/doc/tutorial/doc/class_data_members.html
index 39847ba8..4718880c 100644
--- a/doc/tutorial/doc/class_data_members.html
+++ b/doc/tutorial/doc/class_data_members.html
@@ -56,11 +56,12 @@ Then, in Python:
Note that name is exposed as read-only while value is exposed
as read-write.
- >>> x.name = 'e' # can't change name
+ >>> x.name = 'e' #can't change name
Traceback (most recent call last):
File "<stdin>", line 1, in ?
- AttributeError: can't set attribute
-
Notice that we parameterized the class_ template with BaseWrap as the
second parameter. What is noncopyable? Without it, the library will try
-to create code for converting Base return values of wrapped functions to
-Python. To do that, it needs Base's copy constructor... which isn't
-available, since Base is an abstract class.
+to instantiate a copy constructor for returning Base objects from
+functions.
In Python, let us try to instantiate our Base class:
init<std::string>() exposes the constructor taking in a
std::string (in Python, constructors are spelled
-""__init__"").
+"__init__(...)").
We can expose additional constructors by passing more init<...>s to
the def() member function. Say for example we have another World
diff --git a/doc/tutorial/doc/derived_object_types.html b/doc/tutorial/doc/derived_object_types.html
index 303774f7..4d08db05 100644
--- a/doc/tutorial/doc/derived_object_types.html
+++ b/doc/tutorial/doc/derived_object_types.html
@@ -70,21 +70,18 @@ member functions.
Demonstrates that you can write the C++ equivalent of "format" % x,y,z
in Python, which is useful since there's no easy way to do that in std C++.
-
-Beware the common pitfall of forgetting that the constructors
-of most of Python's mutable types make copies, just as in Python.
-
-Python:
-
- >>> d = dict(x.__dict__) #copies x.__dict__
- >>> d['whatever'] #modifies the copy
-
+ Beware the common pitfall of
+forgetting that the constructors of most of Python's mutable types
+make copies, just as in Python.
+
+ dict d(x.attr("__dict__")); # makes a copy of x's dict
+ d['whatever'] = 3; # modifies a copy of x.__dict__ (not the original)
+
+
+
class_<T> as objects
Due to the dynamic nature of Boost.Python objects, any class_<T> may
also be one of these types! The following code snippet wraps the class
diff --git a/doc/tutorial/doc/quickstart.txt b/doc/tutorial/doc/quickstart.txt
index a8176ec1..ecf3b87d 100644
--- a/doc/tutorial/doc/quickstart.txt
+++ b/doc/tutorial/doc/quickstart.txt
@@ -65,15 +65,10 @@ After this brief ['bjam] tutorial, we should have built two DLLs:
* boost_python.dll
* hello.pyd
-if you are on Windows, and
-
-* libboost_python.so
-* hello.so
-
-if you are on Unix.
+This assumes of course that we are running on Windows.
The tutorial example can be found in the directory:
-[^libs/python/example/tutorial]. There, you can find:
+[^/libs/python/example/tutorial]. There, you can find:
* hello.cpp
* Jamfile
@@ -82,13 +77,12 @@ The [^hello.cpp] file is our C++ hello world example. The [^Jamfile] is a
minimalist ['bjam] script that builds the DLLs for us.
Before anything else, you should have the bjam executable in your boost
-directory. Pre-built Boost.Jam executables are available for most
+directory. Pre-built Boost.Jam executables are available for some
platforms. For example, a pre-built Microsoft Windows bjam executable can
be downloaded [@http://boost.sourceforge.net/jam-executables/bin.ntx86/bjam.zip here].
The complete list of bjam pre-built executables can be found [@../../../../../tools/build/index.html#Jam here].
[h2 Lets Jam!]
-[$theme/jam.png]
Here is our minimalist Jamfile:
@@ -147,9 +141,8 @@ Python modules. Example:
set PYTHON_VERSION=2.2
The above assumes that the Python installation is in [^c:/dev/tools/python]
-and that we are using Python version 2.2. You'll have to tweak this path
-appropriately. __note__ Be sure not to include a third number, e.g. [*not] "2.2.1",
-even if that's the version you have.
+and that we are using Python version 2.2. Be sure not to include a third
+number, e.g. [*not] "2.2.1", even if that's the version you have.
Now we are ready... Be sure to [^cd] to [^libs/python/example/tutorial]
where the tutorial [^"hello.cpp"] and the [^"Jamfile"] is situated.
@@ -193,13 +186,6 @@ If all is well, you should now have:
* boost_python.dll
* hello.pyd
-if you are on Windows, and
-
-* libboost_python.so
-* hello.so
-
-if you are on Unix.
-
[^boost_python.dll] can be found somewhere in [^libs\python\build\bin]
while [^hello.pyd] can be found somewhere in
[^libs\python\example\tutorial\bin]. After a successful build, you can just
@@ -290,7 +276,7 @@ expose instead.
[^init()] exposes the constructor taking in a
[^std::string] (in Python, constructors are spelled
-"[^"__init__"]").
+"[^__init__(...)]").
We can expose additional constructors by passing more [^init<...>]s to
the [^def()] member function. Say for example we have another World
@@ -340,12 +326,10 @@ Then, in Python:
Note that [^name] is exposed as [*read-only] while [^value] is exposed
as [*read-write].
-[pre
>>> x.name = 'e' # can't change name
Traceback (most recent call last):
File "", line 1, in ?
AttributeError: can't set attribute
-]
[page:1 Class Properties]
@@ -498,15 +482,14 @@ polymorphically ['from] [*C++].]
Wrapping [^Base] and the free function [^call_f]:
- class_("Base", no_init)
+ class_("Base", no_init)
;
def("call_f", call_f);
Notice that we parameterized the [^class_] template with [^BaseWrap] as the
second parameter. What is [^noncopyable]? Without it, the library will try
-to create code for converting Base return values of wrapped functions to
-Python. To do that, it needs Base's copy constructor... which isn't
-available, since Base is an abstract class.
+to instantiate a copy constructor for returning Base objects from
+functions.
In Python, let us try to instantiate our [^Base] class:
@@ -837,7 +820,7 @@ or more policies can be composed by chaining. Here's the general syntax:
policy3 > >
Here is the list of predefined call policies. A complete reference detailing
-these can be found [@../../v2/reference.html#models_of_call_policies here].
+these can be found [@../../v2/CallPolicies.html here].
* [*with_custodian_and_ward][br] Ties lifetimes of the arguments
* [*with_custodian_and_ward_postcall][br] Ties lifetimes of the arguments and results
@@ -1024,18 +1007,13 @@ member functions.
Demonstrates that you can write the C++ equivalent of [^"format" % x,y,z]
in Python, which is useful since there's no easy way to do that in std C++.
-__alert__ [*Beware] the common pitfall of forgetting that the constructors
-of most of Python's mutable types make copies, just as in Python.
+[blurb __alert__ Beware the common pitfall of
+forgetting that the constructors of most of Python's mutable types
+make copies, just as in Python.[br][br]
-Python:
-
- >>> d = dict(x.__dict__) # copies x.__dict__
- >>> d['whatever'] # modifies the copy
-
-C++:
-
- dict d(x.attr("__dict__")); # copies x.__dict__
- d['whatever'] = 3; # modifies the copy
+ [^dict d(x.attr("__dict__")); # makes a copy of x's dict[br]
+ '''d['whatever']''' = 3; # modifies a copy of x.__dict__ (not the original)[br]]
+]
[h2 class_ as objects]
diff --git a/doc/v2/acknowledgments.html b/doc/v2/acknowledgments.html
index 071919e3..b2591e6d 100644
--- a/doc/v2/acknowledgments.html
+++ b/doc/v2/acknowledgments.html
@@ -1,32 +1,85 @@
+
+
-
-
-
-Boost.Python - Acknowledgments
-
-
-
Dave Abrahams is
+ the architect, designer, and implementor of Boost.Python.
+
+
Joel de Guzman implemented the default
+ argument support and wrote the excellent tutorial documentation.
+
+
Ralf W.
+ Grosse-Kunstleve implemented the pickle
+ support, and has enthusiastically supported the library since its
+ birth, contributing to design decisions and providing invaluable
+ real-world insight into user requirements. Ralf has written some
+ extensions for converting C++ containers that I hope will be incorporated
+ into the library soon. He also implemented the cross-module support in
+ the first version of Boost.Python. More importantly, Ralf makes sure
+ nobody forgets the near-perfect synergy of C++ and Python for solving the
+ problems of large-scale software construction.
+
+
Achim Domma contributed some
+ of the Object Wrappers and
+ HTML templates for this documentation. Dave Hawkes contributed
+ inspiration for the use of the scope class to simplify module
+ definition syntax. Pearu Pearson wrote some of the test cases that are in
+ the current test suite.
+
+
Martin Casado solved some sticky problems which allow us to build the
+ Boost.Python shared library for AIX's crazy dynamic linking model.
Ullrich
+ Koethe provided the implementation of inheritance and special
+ method/operator support in the first version of Boost.Python.
+
+
The first version of Boost.Python would not have been possible without
+ the support of Dragon Systems, which supported its development and
+ release as a Boost library.
Building an
- Extension Module
Be sure not to include a third number, e.g. not "2.2.1",
-even if that's the version you have.
Beware the common pitfall of forgetting that the constructors
-of most of Python's mutable types make copies, just as in Python.