on Sat Feb 23 2008, "Steve M. Robbins" 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
