Re: [boost] Using multiple versions of Boost

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-05-17 13:07:17

John Maddock wrote:
> Bjørn Roald wrote:
>   
>>> If a bcp based solution becomes useful, I think it should be
>>> considered
>>> to be included in the tool in the boost distribution.
>>>       
>
> Sounds interesting enough to be worth adding: regex based search and replace 
> of namespaces should be easy enough?
>
>   

Well -namespace=boost_1_34_0 actually does a bit more.  It renames 
directories and include directives so stuff like

#include <boost/filesystem/path.hpp>

becomes

#include <boost_1_34_0/filesystem/path.hpp>

and should work.  It also replaces all instances of BOOST_ prefix in 
preprocessor symbol definitions and references with BOOST_1_34_0_ and 
processes Jamfiles as well so my hope was that all should build, test, 
and work without touch up work.

Also in the general case
  
../bin/boost/libs/filesystem/build/libboost_filesystem.a/gcc/debug/libboost_filesystem-gcc-d-1_33_1.a

should become

../bin/boost_1_34_0/libs/filesystem/build/lib/boost_1_34_0_filesystem.a/gcc/debug/libboost_1_34_0_filesystem-gcc-d-1_33_1.a

In this specific case the additional 1_34_0 substrings are just 
annoyance, so I guess we need to treat it as a special case when we have 
a version part of the new namespace.  But as I said library path naming 
is not implemented yet.  I guess this can be done by treating some 
configuration files for the build system.  This may be outside the scope 
of the bcp tool.

So..  given all this, are you still sure this is worth adding? 

Also, is -namespace  the best  name for the command line option?

I have working code and will happily merge with 1.34.0 version of bcp 
and provide you a patch.   Then you can use what you like, fix  what you 
like to fix,  and dump what you don't like :-)

As mentioned earlier, my work on this stopped as my urgent need went 
away 2.5 years ago.    My plan with the code was proof of concept 
prototyping.  So I used the brute force approach where I used regexp 
replace aggressively, then treated a few cases specially as I hit them.  
This worked surprisingly well, so my intention of a next step to move to 
a more robust c++ parsing may not be needed at all.  Anyway, there are a 
few special cases, and the organization of that code is probably 
something that should be re-factored to be more in line with the rest of 
the bcp code.  Maybe even using configuration files rather than 
hard-coding. 

Other issues:

 From my very limited knowledge of boost::regexp, I did not find a way 
to solve replacing

namespace boost
{
...
}

with

namespace boost { namespace 1_34_0
{
...
}} // end namespace boost::1_34_0

Where searching for the ending curly braces is the challenge.  I had 
some success experimenting with boost::expressive, but this code is far 
from ready.  I am also a lot more concerned with parsing issues and 
robustness as I envision many "reasonable" ways to break the matching.  
So my suggestion is to start with the boost::regexp code which works 
well for the simpler use-case.

If anybody want to work on the nested namespace use-case, then I am 
happy to provide them with my code.  I do however not have time to spend 
on this now, sorry.

>>> As the figure illustrate, bcp is a one way tool when you change the
>>> namespace.
>>> I feel strongly that the tool shall be used as a build step rather
>>> than keeping
>>> the modified code under local source control.  The better way is to
>>> do modifications,
>>> patches, testing and contributions for boost as other boost users.
>>> Then
>>> use bcp as a build-time tool.
>>>
>>> To reduce overhead introduced by this build-time, I added an option
>>> to
>>> my bcp version which in case the target file exist only will
>>> overwrite
>>> if file content changes.  This reduces build time dramatically for
>>> changes after initial build.
>>>       
>
> Also a good idea, as long as it's an option: sometimes you want to overwrite 
> the existing file :-)
>   

This code will arrive with the patch.

-- 
Bjørn