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

Subject: Re: [boost] A proposal for superproject structure and testing
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-12 15:10:40

On 12/12/2013 2:05 PM, Cox, Michael wrote:
> 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?

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.