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