On Sat, May 21, 2016 at 6:55 PM, Peter Dimov
Rene Rivera wrote:
You might be interested in the work I've been doing to have a common CI
testing script. The goal is to support testing all libraries, > individually, against a particular Boost version (develop, master, etc). > It's Python so it can handle a bit more logic than easily than sh. And > it's currently used by Predef for its CI testing. Checking out the > subset of Boost that a library requires is something I've had on my todo > list. If you are comfortable enough with Python it would be great if I > could get help in adding features to it :-)
Forgot to provide the link: < https://github.com/boostorg/regression/blob/develop/ci/src/script.py>.
I actually did look at Predef's .travis.yml, but didn't "follow the link" to the script at the time. :-)
Predef is a bit of a special case because it can be tested standalone, most of the libraries need the superproject and their dependencies checked out.
Right.. And it's my intent to support that. Soonish.. Trying to get the release building as solid as possible first though.
I also looked at Antony's script
https://github.com/boostorg/any/blob/develop/.travis.yml
which does check out the whole superproject (and moves the current directory into its proper place); it also appears to be generic.
I however didn't want to use the CI matrix and boot many VMs when one could do. My appveyor.yml for instance has
b2 libs/bind/test toolset=msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0
I found that it's easier to deal with the multiple VMs individually as it's easier to read the results. and if I at some point decide to improve the Travis script to test multiple
g++ versions
Haven't tried that on Travis.. But it's at least not supported for Xcode as each version uses a different image. And the way Travis runs parallel VMs it's faster to just split them up anyway.
and multiple c++ dialects (-std=c++03/11/14...) I would also prefer to use one run for them, and none of the .yml scripts currently in Boost do this.
Note.. They script.py supports TOOLSET=one,two,three. Haven't fully tested that aspect though.
Re
If you are comfortable enough with Python
Python is not exactly my forte. I was thinking of rewriting bpm to issue the appropriate git commands. Something like
bpm init develop bpm install -t bind@SHA bpm test bind
I dislike using C++ for these kinds of tools.. The requirement to compile them makes it cumbersome. Although I have a deadline incoming and I should really stop fiddling with
this while Rome burns. :-)
Yeah, deadlines, oh how I know the feeling :-) By the way, do we really need to package a release on every commit to
develop? :-)
Yes, it's needed. It's how I reduce the likelihood that merging to master will still work for the actual releases. We've had enough problems in the past with this last step not working that I'm ok with it running all the time. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail