[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Boost.Python: Build and Install with Python 2.4 and 2.5?


Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
> 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

First of all, I think you need the configuration to be symmetric, not to
have a "default" build and a "python2.5" one. You need to build things
for python2.4, the same for python2.5 (for all of `pyversions -r`,
actually), and handle the default version afterwards. Otherwise you’ll
need to adapt your build each time the list of supported python versions

> 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 think this is fine.

> 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

Fine too, but please don’t name the directories like this!

> 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

No, for the reason explained above.

> 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 solution is to keep the names decorated with both python versions,
but to maintain a farm of symbolic links pointing to the current python
version. As Steve noted, you don’t need one for the runtime libs, but
for the .a and the .so symlink that are used at build time, this is

You can have a look at e.g. python-gnome2.rtupdate for a simple example
of how to do this.

: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Reply to: