Re: [boost] [Config] Multiple versions of Boost

Subject: Re: [boost] [Config] Multiple versions of Boost
From: Sohail Somani (sohail_at_[hidden])
Date: 2008-09-15 01:31:03

David Abrahams wrote:
> on Fri Sep 12 2008, Sohail Somani <sohail-AT-taggedtype.net> wrote:
> 
>>> #undef BOOST_NAMESPACE_boost
>> Indeed, you are right. Clever too :-)
>>
>> There is one obvious problem I see with the -DBOOST_NAMESPACE=foo
>> approach: there is no way to include two versions of Boost within the
>> same translation unit. Unfortunately, I don't think there would be any
>> acceptable way to do this. Though I'm sure you will come back with a way
>> to do it!
> 
> I think you do that by sticking each version of boost in its own
> namespace, turning off the global namespace alias, and using explicit
> qualification to select the version in question...

This still has the problem that all the Boost source code needs to be
changed to use version-specific macros and version specific includes. So
a version 1.34 header might look like:

#ifndef INCLUDED_BOOST_FUNCTION_HPP_134
...
#include <boost_134/function/detail/base.hpp> // or whatever

I think you can guess what the 1.35 header would look like.

I personally think that two versions of Boost in the same TU can /only/
be solved in an acceptable way by bcp.

> If you want to be ambitious, there's also the issue that some libraries
> (or parts thereof) might want to maintain binary compatibility across
> releases.  Suppose that nothing in Boost.Signals changes between 1.37
> and 1.38.  Should that generate two sets of symbols with
> non-interchangeable types?

Without a totally comprehensive policy for ABI compatibility (good luck
with that one, I'm told!), I have to say yes. Ideally, no, but
practically yes.

-- 
Sohail Somani
http://uint32t.blogspot.com