Boost logo

Boost :

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at