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

Subject: Re: [boost] [Config] Multiple versions of Boost
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2008-09-14 03:13:31

Sohail Somani skrev:
> Steven Watanabe wrote:
>   
>> AMDG
>>
>> Sohail Somani wrote:
>>     
>>> Sohail Somani wrote:
>>> [snip]
>>>  
>>>       
>>>> 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?
>>>>         
>> In order to make this work we need to make sure that
>> there is a namespace alias where appropriate:
>>
>> #if !defined(BOOST_NAMESPACE)
>>    #define BOOST_NAMESPACE boost
>> #endif
>>
>> #define BOOST_NAMESPACE_boost 0
>>
>> #if BOOST_PP_CAT(BOOST_NAMESPACE_, BOOST_NAMESPACE)
>>    namespace BOOST_NAMESPACE {}
>>    namespace boost = BOOST_NAMESPACE;
>> #endif
>>
>> #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!
>   

Even if you solve this for the namespace, you can not safely have 
side-by-side headers from two boost versions in the same translation 
unit.  You still have the issues of include paths and all the other 
BOOST_ preprocessor symbol definitions.  There are probably other issues 
as well that is off my radar screen.  Namespace  variations only solve 
part of the issues, but if you don't mix boost versions in the same 
translation units you may be Ok.  However, if you need to use boost 
types in interfaces used across boost versions -- then you need a 
different solution. The types need adapters, or they need to be aliased 
and binary compatible. 

> By the way, I've received a message on IRC telling me that Xalan and
> Xerces do something very similar so it wouldn't be totally unprecedented

I was never pleased with the limitation of the Xerces method.  So, some 
years ago I did  some testing with a different approach to solve this.  
I used a patched version of the bcp tool to manipulate names of 
preprocessor symbol names, include paths, and namespace names in a copy 
boost (or of selected boost libriaries) copied with bcp.  I did some 
promising tests  and posted a patch to the list.  I think Eric Niebler 
reported some success in using this approach.

-- 
Bjørn Roald