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:
> 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:
> This produces pairs of library files such as
> (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
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.
Sounds more likely to work, even though it's ugly.
> 3. Put the libraries in different subdirectories, e.g.
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.
> 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?
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.
-- Dave Abrahams Boost Consulting http://boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk