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