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