on Sat Feb 23 2008, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
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
Well, you can run it once: bjam python=2.4,2.5 IIRC.
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.
I don't know how such name gristing is generated in Boost.Build, but IMO we should change the naming to account for the Python version. This is really a question for the Boost.Build list, I think.
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
I'm not an expert in this area, but it's been my understanding that simply renaming library files doesn't work for some reason.
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
Sounds more likely to work, even though it's ugly.
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
You could do that, and then provide symlinks with the python version grist in /usr/lib
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.
Understandable.
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?
Unfortunately, we don't tend to get a lot of interaction with packagers around here, so we don't tend to know what they're doing. I think Boost raises more packaging issues than most other libraries, so it would be good to have more involvement from y'all.
In principle, it would be nice to have the Boost libraries named the same across distributions.
No doubt! -- Dave Abrahams Boost Consulting http://boost-consulting.com