Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?

From: David Abrahams (dave_at_[hidden])
Date: 2008-05-01 10:30:32

on Thu Mar 13 2008, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:

> Actually, the only thing about Boost that causes grief to packagers is
> that the toolset name (e.g. "gcc42") is embedded in the library
> filename.  I just wrote a response on Boost.Build outlining this in
> some detail [1].  Embedding the compiler version requires Debian to
> rebuild all the boost packages each time a compiler change is made.
> This is unnecessary when the compiler ABI is maintained (e.g 4.1 ->
> 4.2) and also unnecessary when the ABI is broken, as Debian has
> another mechanism to handle that.  Note that rebuilding the boost
> packages has a huge ripple effect, so it is more than simply
> "unnecessary", it is a very large headache.

I'm not sure that's the end of the story.  One reason we embed the
compiler name in the library name is that version-specific workarounds
often show up in header files.  The result is that when compiled against
gcc-4.2, client code will effectively see different header contents than
the precompiled boost library that was built with gcc-4.1 did.  I think
we'd need to work out a discipline of avoiding BOOST_WORKAROUND code in
headers that distinguishes compiler minor versions.  I'm not very
confident that I've thought that issue through completely... is it that
simple?

> The fact that Boost embeds the Boost version in the library name is
> cause for grief to client software authors.  But this is unavoidable
> as long as Boost doesn't take care to maintain ABI across versions.
> Fortunately, there is a simple solution to this, which I touch on in
> my post [1].

This is just a change to bjam?  Have you gotten any traction with that
idea?

-- 
Dave Abrahams
Boost Consulting
http://boost-consulting.com