[boost] [Config] Multiple versions of Boost

Subject: [boost] [Config] Multiple versions of Boost
From: Sohail Somani (sohail_at_[hidden])
Date: 2008-09-12 19:41:22

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