[C++-sig] my experiences with boost/python so far
randre at pppl.gov
Tue Apr 9 21:42:39 CEST 2002
I am relatively new to the boost/python library so I thought I would relate
some of my experiences with using boost on a dual processor,
linux mandrake 8.0, 2.2 kernel with gcc 3.0.4:
1) building requires a magic command. I probably missed the documentation somewhere
but my magic command turned out to be
jam -sBOOST_ROOT=/home/randre/cvs/boost -sTOOLS="gcc" -sPYTHON_ROOT="/usr/local" \
If I leave off the PYTHON_LIB_PATH I get the failure,
Couldn't find Python 2.2 installation in /usr/local
skipping Boost.Python library build
You can configure the location of your python installation, by setting:
PYTHON_ROOT - currently "/usr/local"
PYTHON_VERSION - currently "2.2"
PYTHON_INCLUDES - configured from PYTHON_ROOT, currently "/usr/local/include/python2.2"
PYTHON_LIB_PATH - configured from PYTHON_ROOT, currently "/usr/local/lib/python2.2/config"
...found 402 targets...
To test, I had to add -sGCC_ROOT_DIRECTORY=/usr/local with the target 'test' because
I use LD_LIBRARY_PATH (I know I shouldn't) and it gets reset by the test. The pickle
tests always seem to fail for me.
Is there a way to see what gcc-C++-action and gcc-Link-action are doing?
2) I've had no luck in compiling boost on any system with gcc 2.9* because of the
template instantiation support -- so much for Mac OS X.
3) creating a single module worked fine but when I started using two modules built
with boost I would get seg faults deep within stringstream -- something to do with a
missing character_trait used in double conversions. I'm guessing a compiler bug or
I built my gcc incorrectly. I finally had to force the use of the deprecated
strstream in operators.hpp.
4) I created an exception class derived from std::exception. Generally this works but
sometimes the exception type gets lost somehow and I end up with the python
message 'RuntimeError: unidentifiable C++ exception' instead of my nice error
message. Exceptions were very unstable until I compiled gcc with the
5) The function overloading and cross module support are really really cool.
6) I'm not totally sure of what I am doing when I make to_python() and from_python()
functions. The reference class looks good but I have to study it to
figure out what is going on with the reference counting. The to_python(PyObject*)
does not transfer ownership the way I thought it would for ordinary functions so I
ended up wrapping a PyObject* in my own TransferPyObject class with a
to_python(TransferPyObject) which transfers ownership. There's probably a better way.
7) Overall I am very impressed with the ease of building a C++ extension but I am never
quite sure what will happen when I run the extensions and I haven't stressed tested
them. I'm hoping gcc 3.1 solves some of my issues because solid linux support is
required for what I am doing. Are there any other compilers for linux which work with
boost/python or do other gcc users not have these problems? I've got a few other
unix architectures which I will eventually test it on.
More information about the Cplusplus-sig