Re: [boost] A proposal for superproject structure and testing

On 12/12/2013 2:05 PM, Cox, Michael wrote:

On Thu, Dec 12, 2013 at 6:09 AM, Peter Dimov wrote:

...

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?

The other way around. If you have dependencies on other libraries you can run your 'develop' tests with the 'develop' branch of those other libraries. Then you can notify some dependent library if their changes break your own tests. I would also run the 'develop' tests against 'master' for all libraries also at some time. This is no difference in principal than developing any other software.

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?

No one except regression testers is tasked with this.

...

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?

It's just a suggestion, I believe. In Windows I use various releases of gcc and VC++. In Linux various releases of gcc, clang, Intel C++, and occasionally Sun C++, although the latter is a bit buggy. If you have C++03 aned C++0x features you try to test both sides.