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

From: Steve M. Robbins (steve_at_[hidden])
Date: 2008-05-01 12:27:13

On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote:
> 
> 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.

Interesting.  I didn't know that.  Debian's "unstable" distribution
has been using the same compiled Boost libraries with a mix of GCC 4.1
and 4.2 since December.  GCC 4.3 is being added to the mix, too.

I should grep the boost headers for BOOST_WORKAROUND to see what
differences might arise.

> 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?

If possible, that would be nice from a library distributor's 
point of view.

> > 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?

It turns out to be simpler than that.  With a small tweak to boost's
Jamroot file, I'm now generating libraries without the toolset and
without the Boost version decorations.  I will use this for the
upcoming Boost 1.35.0 Debian packages.

We had a long thread in Boost.Build about this idea [1].  I'm not sure
I convinced anyone to my point of view.  :-)  We'll proceed with
Debian-specific changes for the short term and see how it goes.

Regards,
-Steve

[1] Thread starts at
    http://lists.boost.org/boost-build/2008/04/18835.php
The shortest statement of Debian's position is
    http://lists.boost.org/boost-build/2008/04/18839.php
(And please ignore http://lists.boost.org/boost-build/2008/04/18918.php
 as I've changed my mind again)