Re: [boost] Breaking existing libraries
FWIW, if you're a Windows/MSVC user, then building fresh Boost release takes about 5 mins of human work, and boost-build@lists.boost.org can provide assistance if anything goes wrong.
Because of the way the MSVC STL is implemented, we have to make sure the compiler options (specifically, the one disabling iterator checking in release-mode builds) match. We also want the WPO/PGO and some other settings to match. And we need to be able to change those settings globally in a build to accommodate, for instance, Compuware's code analysis tools that don't run when you enable too much optimization. So we build the compiled boost libraries we are using as part of our product build. Avoiding ODR (one-definition rule) violations is hard. Avoiding them across the MSBuild / boost build chasm is very hard. NP-annoying hard, not NP-hard hard. But hard enough. The one-on-one help you provide, Vladimir, has been of great value. I admire your energy and your dedication to the task. But I'd also like to have a design and documentation that doesn't require an entire semester of study to reach the level where I have some idea why one syntax works and another doesn't. MSBuild is no better. I have to be able to get work done in both. Sigh. -swn
Stephen Nuchia wrote:
FWIW, if you're a Windows/MSVC user, then building fresh Boost release takes about 5 mins of human work, and boost-build@lists.boost.org can provide assistance if anything goes wrong.
Because of the way the MSVC STL is implemented, we have to make sure the compiler options (specifically, the one disabling iterator checking in release-mode builds) match. We also want the WPO/PGO and some other settings to match. And we need to be able to change those settings globally in a build to accommodate, for instance, Compuware's code analysis tools that don't run when you enable too much optimization. So we build the compiled boost libraries we are using as part of our product build.
Oh, matching existing build system *exactly* to the degree of not breaking external tools with too much optimization is certainly not a trivial task as just getting Boost for MSVC, I agree.
Avoiding ODR (one-definition rule) violations is hard. Avoiding them across the MSBuild / boost build chasm is very hard. NP-annoying hard, not NP-hard hard. But hard enough.
The one-on-one help you provide, Vladimir, has been of great value. I admire your energy and your dedication to the task. But I'd also like to have a design and documentation that doesn't require an entire semester of study to reach the level where I have some idea why one syntax works and another doesn't.
FWIW, some bits of docs were rewritten for 1.37, and some more are in the queue. - Volodya
participants (2)
-
Stephen Nuchia -
Vladimir Prus