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)
signature.asc
Description: Digital signature