Re: Boost.Python: Build and Install with Python 2.4 and 2.5?
on Thu Mar 13 2008, "Steve M. Robbins" 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]
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
On Thu, May 01, 2008 at 10:30:32AM -0400, David Abrahams wrote: > > on Thu Mar 13 2008, "Steve M. Robbins" 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
Re: [Boost-build] Boost.Python: Build and Install with Python 2.4 and 2.5?
Steve, Steve M. Robbins wrote: 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. By all means, could you please get together with other packagers (fedora, notably) and try to establish a common procedure ? (Ideally this procedure would be christened by boost itself, eventually, but unfortunately I just don't see that happening anytime soon.) This is really a big usability issue for developers who want to develop on platforms such as debian or fedora, but still remain as portable as possible, as they have to be prepared for lots of subtle and not-so-subtle variations, complicating their life unnecessarily. It's bad enough that there is no API & ABI stability guarantee from one boost version to the next... Thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
