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

Subject: Re: [boost] [CMake] what to do now?
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-16 10:37:00

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.