I haven't tried if a -Dboost=boost_1_43 preprocessor flag (applied to both the boost build and the application build) is sufficient, though.
There is my small python script that renames boost [1]. It renames all includes and defines so you can simultaneously use several boost version in same code.
Thanks for the pointers. This already sounds very useful for bundling boost. Actually, I'd think it would also solve your problem: you could bundle a renamed boost and control yourself what updates you allow. Thereby you allow a binary stable build. Yet it would be still possible to provide a compile time flag to use the system boost instead. So people comfortable with a changing ABI can avoid having two boosts, and people uncomfortable with it don't need to have that issue. But what I would like even more to see would be boost solving the renaming problem without copying, by just using the preprocessor. Think replacing all the namespace boost { ... } with something like: BOOST_NS_START .. BOOST_NS_END ..and boost::foo with BOOST_NS::foo. Then the BOOST_NS* macros could allow to have preprocessor-controlled namespace naming.
Also latest BCP version allow you to do similar job, but it does not rename includes and macros so you can't include two boost version in same C++ code.
I do not see a point in using two boost versions in the same compilation unit. This would just increase code size.
Note: my script was written before BCP provided such option.
**BUT!!!!** It does not solves all problems:
1. There is a code placed in tr1 namespace - it would collide if you use it. 2. Some libraries that provide extern "C" functions do bad job and pollute global namespace with these symbols. They collide as well.
Examples: - Boost.Thread: https://svn.boost.org/trac/boost/ticket/3812 - Boost.Test: https://svn.boost.org/trac/boost/ticket/3811 - LW Thread: https://svn.boost.org/trac/boost/ticket/3810
But in some libraries this behavior is actually design. For example boost.regex provides POSIX regex API regcomp(A|W), regexec(A|W) that go directly to global namespace.
Thanks for the pointers. I think it would be a great benefit for boost to make all these global names preprocessor-configurable.
P.S.: as you can see it is quite non-trivial issue.
I already feared it was that way :). But I think this is the way to go. Maybe we can have multiple-parallel-boost-versions regression tests some day. But this would call for a distributed SCM system like git for boost development, so an automated test could pull an older (incompatible) version to compile against without bothering the svn server all the time. Best regards, Isidor