Boost logo

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>


#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

should become


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

Other issues:

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

namespace boost


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at