Re: [boost] Using multiple versions of Boost

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2007-05-17 13:33:51

Piyo wrote:
> Bjørn Roald wrote:
>
>   
>> 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 
>>     
>
> Our programmers perfer this nested namespace style so I am definitely
> interested in bcp if it can do it.
>   

In that case you need to look at a different version of my code than the 
one I suggested for John Maddock to include in bcp.  Also you have to 
expect some work to get it usable, but I am convinced it can be done.

>> 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.
>>     
>
> Does this mean that the regexp based code cannot do nested namespaces?
>   

Assuming my knowledges of regexp is correct, this is tricky and may not 
be possible in a robust way at all.

> If so, is it possible to keep the dependency on regexp and yet still
> have nested namespaces or is the expressive dependency a must?
>   

expressive is not a must, only a possible solution.  And in any case, we 
are only talking about the bcp code anyway, not your code.  John Maddock 
may prefer a different solution than xpressive if this feature ever 
reaches the standard version of the bcp.

>> 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.
>>     
>
> Either way, I can test it before I spam the facility :) So yes, I can
> test bcp.
>   

If you want to have nested namespace support.  Then more than testing is 
needed from you.  A working implementation is needed.

>
>   
>> 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.
>>     
>
> I see your point but at least in our facility there is only a handful
> of developers that are interested in contributing to boost.
> The rest are users (only a handful also as I am actively
> trying to evangelize users). I am leaning towards permanently changing
> the namespaces to our facility for regular users and for those
> interested can still download boost sources and contribute directly.
>   

I know this may seem complicated to set up, but consider writing test 
cases, reporting bugs, testing patches,  and contributing to boost as 
something  that becomes natural with one setup, and very awkward with 
the other.

>> 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.
>>
>>
>> Help is offered ;-)  Anyone ready to try this can mail me off the list 
>> if you prefer.
>>     
>
> BTW, if you want to take this off-line, feel free to email me directly.
>   

No need from my side, but at some point we are probably only spamming 
the list ;-)

> I am ready to test it when you are :)
>   
Let me sort out where John want to go first, then I will be back to 
you.  If you want the code as is and start working yourselves, then it 
is one mail away.  I do not want to post anything to the list or 
elsewhere before it is merged and tested with 1.34.0.  And that includes 
testing with Boost.Build v2.

-- 
Bjørn