Piyo wrote:
I am open to any form of solution whether it be macro-based or bcp
If you intent to test the bcp approach, my code is a good way to start. I looked it up, and I have several versions of it available. The latests version introduces boost::expressive as dependency to bcp to handle changing boost to nested namespaces like boost::1.34.0. This code is as far as I remember not complete, so the best start would be the earlier version based on boost::regexp only. If this is what you want to try, I will send you the code. I did a quick diff against a resent cvs version of boost, and it seems that there are a few changes to bcp we want to merge in. If you are interested and give me a few days, I will find time to merge and test the merged version a bit for you. If a bcp based solution becomes useful, I think it should be considered to be included in the tool in the boost distribution. As of now I think we need some more prof of the usefulness of the concept, and I think documentation is needed as to the best ways to use such a tool. Maybe some conventions can be introduced for naming and how the tool is used in the configuration management. Here is a simple sketch of my ideas: boost.org | my_place.com ------------+--------------------------+-------------------------------- central SCM | local CM/SCM | build environment ------------+--------------------------+-------------------------------- repo <--svn--> namespace boost | --bcp-> namespace mylib_boost | | | do your boost work here | bcp used as a build step only 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.
or Xerces style. I just find it sad that I am stopping 1.34 from entering our company on purpose because I do not think that adding to our existing 1.32 and 1.33.1 installations will help. Is there anyway we can get the core boost developers to look into this? Since I am the only boost-evangelist here, I can't imagine me stopping progress over something like this.
HELP!! :)
Help is offered ;-) Anyone ready to try this can mail me off the list if you prefer. -- Bjørn This file contains notes regarding enhansements to BOOST_ROOT/tools/bcp to support replacement of the boost namespace in sourcecode copied from the boost distrubution. ==================== HOWTO ====================== A new option: --namespace=ns set a namespace that will replace 'boost' is added to the bcp tool. This allow the user to specify a namespace to use as replacement for boost in exported source code. example use:
cd ~/src/boost mkdir -p /tmp/testbcp/mylib tools/bcp/run/bcp -cvs -namespace=mylib filesystem /tmp/testbcp/mylib
later you can use
tools/bcp/run/bcp -cvs --namespace=spoost --diff-only filesystem /tmp/testbcp/mylib
to only do the changes You can add boost-build.jam Jamfile Jamrules to the module-list on the bcp command line to get the top level build files needed to build the exported code. If you change the following 2 lines in the exported Jamfile [ glob-tree $(BOOST_ROOT)/boost/compatibility/cpp_c_headers : c* ] [ glob-tree $(BOOST_ROOT)/boost : *.hpp *.ipp *.h *.inc ] to [ glob-tree $(BOOST_ROOT)/mylib/compatibility/cpp_c_headers : c* ] [ glob-tree $(BOOST_ROOT)/mylib : *.hpp *.ipp *.h *.inc ] you can actually build the exported libraries with bjam. NOTE: see limitation regarding Boost.Build ================== TODO ========================= 1. Support replacing namespace boost with nested namespace, e.g. namespace boost ====> namespace mylib::boost or namespace boost ====> namespace mylib::stuff::platform 2. Better Boost.Build and Jamfile support in export =============== LIMITATIONS ====================== 1. Only replacement of boost namespace with single level namespace is suported. No replacement with nested namespace supported jet. 2. Boost.Build export not suported properly. Buildfiles are still configured for the "boost" name after export. E.g. libriaries built contain the string "boost" in their filenames.