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. 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 and if I at some point decide to improve the Travis script to test multiple g++ versions 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. 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 Although I have a deadline incoming and I should really stop fiddling with this while Rome burns. :-) By the way, do we really need to package a release on every commit to develop? :-)