Le mardi 26 février 2008 à 22:04 -0600, Steve M. Robbins a écrit : > The idea is to create a single -dev package that contains the > following in /usr/lib: > > libboost_python-py24-gcc42-1_34_1.so > libboost_python-py24-gcc42-1_34_1.a > > libboost_python-py25-gcc42-1_34_1.so > libboost_python-py25-gcc42-1_34_1.a > > The -dev package contains an rtupdate script to create the following > symlinks (also in /usr/lib): > > libboost_python-gcc42-1_34_1.so > libboost_python-gcc42-1_34_1.a > > Does that sound right? Yes. > This has the advantage that a Python extension can be build and > packaged for either or both supported Python versions, albeit at the > cost of changing the link line. Code that just needs the default > version can use the undecorated form in the link line. The > disadvantage is that if you use the undecorated form, you're not quite > sure what version of Boost.Python is linked in. This sounds good as this way, extensions using boost can be made to build with all available python versions. It would be nice to have libboost_python2.4.so and libboost_python2.5.so symbolic links as well, so that building an extension for all available python versions doesn’t require setting the GCC version and boost version in the link line. -- .''`. : :' : 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?=