Re: [boost] b2 looks for tools/inspect/build/Jamfile

Subject: Re: [boost] b2 looks for tools/inspect/build/Jamfile
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-05-21 22:08:05

On Sat, May 21, 2016 at 6:55 PM, Peter Dimov <lists_at_[hidden]> wrote:

> 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_at_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