Subject: Re: [boost] A proposal for superproject structure and testing
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-12 14:05:28
On Thu, Dec 12, 2013 at 6:09 AM, Peter Dimov <lists_at_[hidden]> 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? 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