Re: [boost] Using multiple versions of Boost

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-05-16 22:09:26

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.