[C++-sig] my experiences with boost/python so far

[Robert Andre]

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" \
         -sPYTHON_VERSION=2.2 -sPYTHON_LIB_PATH="/usr/local/lib/python2.2"

   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 
   --enable-sjlj-exceptions option.

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.

rob andre