[boost] Boost.Python: Build and Install with Python 2.4 and 2.5?

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-02-23 23:45:18

Hi,

I'm part of the Debian Boost packaging team, seeking some guidance on
how to build and install Boost.Python so that it is usable with all
Python versions shipped in Debian.  Debian currently ships Python 2.4
and 2.5.

When reading the following, keep in mind that Boost.Python is not a
Python extension but, rather, a library that eases writing an
extension in C++.  So it is necessary that the compiled libraries be
visible to be linked with user-written C++ code.

One idea is to use a user-config.jam file containing

        using python : 2.4 : /usr ;
        using python : 2.5 : /usr ;

Then run jam twice

        bjam variant= ...
        bjam variant= ... python python=2.5

This produces pairs of library files such as

        bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a
        bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a

(and similar pairs for shared libraries and all other variants).

The key item to note is that the two files have the same name.  The
python version, unlike the GCC version, is not embedded in the library
name.  So these files cannot both be installed into /usr/lib.

The question, then, is how to distinguish them once installed?  
Should we:

1. Rename the resulting libraries to decorate them with the python
version in addition to the gcc version?  This could generate

        libboost_python-py24-gcc42-1_34_1.a
        libboost_python-py25-gcc42-1_34_1.a

2. Similar to above, but use bjam's --buildid option?  This has the
drawback that the build ID shows up differently than the GCC version
decoration, e.g.

        libboost_python-gcc42-1_34_1-py24.a
        libboost_python-gcc42-1_34_1-py25.a

3. Put the libraries in different subdirectories, e.g.

        /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a
        /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

4. Put the default version directly in /usr/lib and the others
in subdirectories, e.g.

        /usr/lib/libboost_python-gcc42-1_34_1.a
        /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a

The drawback to all these approaches is that client code has to be
adjusted to build on Debian.  Linking against Boost (for non-bjam
projects) is already hard enough with the decorated library names that
I fear making the situation worse.  

The attraction of #4 is that at least the variants for the default
python version are found in a natural manner.  This has some appeal to
me, personally, but I worry that it is too easy to build an extension
to python 2.5 and link in the wrong Boost.Python library.  In
contrast, the other options have the advantage that it forces the user
to declare which version of Python is being used.

I'd appreciate your thoughts.  Have I overlooked a better solution?
What are the other packagers of Boost.Python doing?  In principle,
it would be nice to have the Boost libraries named the same across
distributions. 

Thanks,
-Steve