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 ?