Re: [boost] [CMake] what to do now?

Subject: Re: [boost] [CMake] what to do now?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-04-16 11:18:50

On 4/16/2016 10:37 AM, Peter Dimov wrote:
> Rob Stewart wrote:
>> Paul and Louis are arguing in favor not only of convention, to avoid
>> user surprises, but of enabling cget, Travis, Appveyor, and other
>> tools that will help Boost generally, or library authors/maintainers
>> individually.
>
> While I agree 120% with Rene's post
>
>     http://lists.boost.org/Archives/boost/2015/06/223027.php
>
> I wouldn't be opposed to libraries having a top-level .travis.yml,
> appveyor.yml and CMakeLists.txt, because, well, the alternative is not
> supporting Travis/Appveyor/generic CMake tooling.
>
> After taking a look at Travis and Appveyor, I now better understand
> Stefan Seefeld's desire to support compilation of Boost.Python against a
> system-installed Boost, because this is the environment that's easy to
> achieve on Travis (Boost 1.55 available via apt-get.)
>
> For people who prefer to match our current testing, where the develop
> library is tested against its develop dependencies, Travis isn't very
> suitable. It checks out the library repo but knows nothing about the
> superproject, so basically one has to re-download the library again
> using the proper structure.
>
> If all libraries had CMakeLists.txt (and no cyclic test dependencies),
> cget --test could do it. Otherwise, when I at some point get some free
> time and implement my plan for the next iteration of bpm, it would be
> able to do it as well.
>
> Travis and Appveyor are no match for our test matrix because they only
> have "mainstream" compilers which I either have, or which correlate
> strongly with those I have, but the approach itself is interesting as
> something that we may need to think how to duplicate for our purposes.
> That is, our test infrastructure could activate on commit as Travis does.
>
> On the other hand, there's also the fact that a commit in a dependency
> may break a library without it changing.

Are you envisioning a test infrastructure "activating" as meaning that 
it will only test the library for which the commit is made ?