|
Boost : |
Subject: Re: [boost] [Config] Multiple versions of Boost
From: David Abrahams (dave_at_[hidden])
Date: 2008-09-13 22:01:16
on Fri Sep 12 2008, Sohail Somani <sohail-AT-taggedtype.net> wrote:
> 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.
This is a longstanding issue for C++ libraries in general, and for Boost
in particular. I know for a fact there are several companies out there
that struggle with it.
We already do something like the above for Boost.Signals because of
potential conflicts with Qt. I think it's worth taking a look at how
Boost.TR1 does its business, and we should probably also be thinking
about how to leverage namespace aliases.
I don't know if anyone at Boost has taken the time to solve the problem
in general, so I'm really glad to see the issue raised.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk