Recently, I had the pleasure of integrating a statically linked library that used a version of Boost different from the one I was using. All relevant compiler flags matched. Only the Boost version was the problem. Fortunately, I was able to solve the problem by getting the provider of the statically linked library to rename the Boost namespace by passing in -Dboost=boost_133_1_provider to their compiler. This worked fine for them. Obviously part of this solution involved them rebuilding the part of boost that was important to them in the same manner, but we always build Boost ourselves don't we? Anyway, I thought it might be a good idea to do the same on the larger code base so I attempted to do the same. Failed miserably. The problem is that some of the Boost code contains some variant of: #if defined(SOME_CONDITION) # define HEADER <boost/some/header.hpp> #else # define HEADER <boost/some/other/header.hpp> #endif #include HEADER Reading 16.2/4, it seems that the behaviour in this case is not defined. Specifically, an implementation may or may not replace the boost text with boost_133_1_provider. This is true whether or not you have <boost/some/header.hpp> or "boost/some/header.hpp". So on one compiler, you may end up with: #include <boost_133_1_provider/some/header.hpp> And on another: #include <boost/some/header.hpp> My immediate problem solved, I made do. However, the problem still bugs me. There should be /some/ way to do this. So... What if Boost.Config did something like: #if !defined(BOOST) # define BOOST boost #endif And we replace all uses of the boost namespace with BOOST? Would such a patch against trunk be acceptable? What are the problems? I know it isn't aesthetically pleasing but it might have made this a bit easier. -- Sohail Somani http://uint32t.blogspot.com