On Thu, Dec 12, 2013 at 6:09 AM, Peter Dimov
Cox, Michael wrote:
I don't expect the criteria to merge changes from a feature branch to the develop branch to be successful builds/tests for *all *supported compilers/platforms (that sounds like a good criteria for merging the develop branches into the master branches). I would expect something along the lines of an incremental build of a freshly pulled set of repositories and running the tests for your compiler/platform.
Sure, that's just common sense and basically what we've been already doing. A change to the public develop branch (the svn trunk in the old world) implies that local testing *of the submodule* has been done. Not of all of Boost; this takes too much time even on a single compiler/platform. (This doesn't specify whether the local change to the develop branch has been a feature branch merge or something else; it doesn't matter.)
Yes, but common sense is just so uncommon these days :-). Does "local testing * of the submodule*" include running the unit-tests of the the other submodules to see if you've broken anything in someone elses submodule that depends on yours? And BTW, I was Googling and looking through Boost.Build documentation and couldn't figure out how to easily run all the tests for all the libraries. I would assume there is a target you could pass b2 to run all the unit-tests. What is it?
In practice, a single compiler is not enough; on Windows, one needs at least one version of MSVC, at least one version of GCC, at least one non-C++11 compiler, at least one C++11 compiler.
Wow, that's a lot of combinations. Is that the "official" Boost policy, i.e. is there a link on the web-site I can read this? Will that be the official policy for all Boost libraries or can individual libraries define their own? Michael