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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]