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

[Ralf W. Grosse-Kunstleve]

--- Robert Andre <randre at pppl.gov> wrote:
> 
> 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. 

I am working with Boost.Python V1 under Linux (RedHat 7.1) all the time.
The only problem is that 2.95.x exception handling is seriously buggy.
However, most extensions work if compiled with -g. gcc 3.0.4 does not
seem to have this problem.
I am also using LD_LIBRARY_PATH, both with gcc 2.95.x and 3.0.4.
I am using my own makefiles for building the extensions. See
boost/libs/python/build/linux_gcc.mak for an example.

> The pickle
>    tests always seem to fail for me.

This problem is fixed in Python 2.2.1c2 (and therefore hopefully 2.2.1 final).
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

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

As indicated above, in general 2.95.x should work for Boost.Python.
However, somehow Apple managed to break the OS X derivative of
the compiler. It reports "missing symbols" at the link stage.
I do not know of a fix or work-around. 

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

I am puzzled. But my CVS snapshot is a couple of weeks behind...

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

I am puzzled again. gcc 3.0.4 installed with ./configure; make bootstrap
seems to work for us.
 
> 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.

Did you look at the examples, in particular do_it_yourself_convts.cpp?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/