From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-17 04:54:24
Andrey Melnikov wrote:
> Reece Dunn wrote:
>> ...> echo Bugfixes for foo > desc.txt
>> ...> bjam checkin-cvs branch=RC_1_34 desc=desc.txt
>> ...> bjam diff-cvs # diff files with latest version
>> ...> bjam diff compare-with=...
>>I am not sure how these will work with BBv2, but this is the sort of
>>thing I am referring to.
> Do you mean you want a unified command line interface to version control
In the same sense that BB/SCons offer a unified interface to C++
compilers (and tools in general). Don't forget that I am just generating
ideas. I have absolutely no idea what the final syntax/usage would be.
The *really* big thing would be where you could to:
update sync-cvs : dir=. : <toolset>cvs ;
exe regression-test : ... //sync-cvs ;
and BB will automatically sync with the latest code from CVS. Or you
bjam ... label=Build10
to automatically sync with Build10 of the codebase and perform the tests
with that. You could also do this with a project build so you could go
back to earlier builds of that product and run tests for it.
You could even use this to automate logging the changelist number/date
that the build occurred, so you have a log of what version of the
codebase you are using.
Also, if you wanted to go all out, you could add the build log into the
VCS after the build has finished.
I am not proposing that any of the syntaxes I have shown is the one we
should use, but showing how you could leverage such a system to either
automate it in the build (as above), or use it to get a unified
(simpler) command-line interface. This would be a major win as I don't
have to spend time looking up the commandline to get an RCS diff, for
However, that all said, I am not sure exactly how this all fits into the
BB model. Think of this as the concept phase: what do people want out of
this? How can we make those tasks easier?
For any major development work, you need to have some sort of VCS. This
will be tied directly to the develop-checkin-build-test cycle as well as
the nighly builds and test reports. Being able then to tie the VCS
management into the build system gives a developer greater power.
For example, if someone said there was a serious crash in
Boost.Filesystem for example in version 1.30 with gcc, you could do:
bjam gcc debug label=1_30
build the sample code you were given and check out the issue. Once
located, you can see if it is an issue with the current codebase.
Or if you were developing on Firefox and someone said there was an issue
with the 2005-08-20/9:15 build, where you wouldn't necessarily have a
binary snapshot. It would be easier just to tell the buildsystem to
build the product using a specific version from the VCS.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk