Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

From: David Abrahams (dave_at_[hidden])
Date: 2008-03-12 21:11:25

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