From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-05-16 22:09:26
> 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
I feel strongly that the tool shall be used as a build step rather than
the modified code under local source control. The better way is to do
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.
> 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.
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.
> 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 ]
[ 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
================== TODO =========================
Support replacing namespace boost with nested namespace, e.g.
namespace boost ====> namespace mylib::boost
namespace boost ====> namespace mylib::stuff::platform
Better Boost.Build and Jamfile support in export
=============== LIMITATIONS ======================
Only replacement of boost namespace with single level namespace
is suported. No replacement with nested namespace supported jet.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk