Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)

Subject: Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-02-16 14:19:17

On 2/16/2016 12:17 PM, Rene Rivera wrote:
> On Tue, Feb 16, 2016 at 10:34 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>
>> On 2/15/16 10:27 PM, Vladimir Prus wrote:
>>
>>> On 15-Feb-16 8:16 PM, Robert Ramey wrote:
>>>
>>>> On 2/15/16 8:37 AM, Steven Watanabe wrote:
>>>>
>>>>> AMDG
>>>>>
>>>>> On 02/15/2016 09:19 AM, Robert Ramey wrote:
>>>>>
>>>>>>
>>>>>> To me, more urgent is the problem associated with b2 on cygwin.  I've
>>>>>> noted on this list.  Basically if one builds b2 using the bootstrap.sh
>>>>>> under cygwin it seems that it get's the / and \ mixed up in the
>>>>>> pathnames.  And this prevents b2 from working correctly.  I wouldn't be
>>>>>> surprised if this isn't also a problem with mingw on windows as well.
>>>>>> I'm guessing this probably an easy fix for you.
>>>>>>
>>>>>>
>>>>> Did my patch not work?
>>>>>
>>>>
>>>> Honestly, I haven't had time to get back to this yet.
>>>>
>>>
>>> So, the summary of this thread is that the ball is in your court?
>>>
>>
>> I have made a personal commitment to maintaining the boost serialization
>> library.  So the "ball is ALWAYS in my court".
>>
>> In order to fulfill this commitment, I depend on a number of resources:
>>
>> a) my personal time
>> b) my own computer hardware
>> c) other boost libraries - the library depends upon other boost components
>> such as boost spirit
>> d) boost build - b2 etc.
>> e) boost regression testing setup up
>>
>
> The same applies to all of us. (A)
>
> What do I do when one of the above resources fails to work as advertised?
>> This is the question I face.  In many cases, personal time, hardware, etc.
>> I try to make adjustments.  Sometimes this means delay in response time,
>> etc. Sometimes this means me taking on things that are incidental to the
>> library maintenance such as testing a fix in some other component, etc.
>>
>
> The same applies to all of us. (B)
>
> So, the ball is in my court, but that doesn't mean it's not in other courts
>> too!
>>
>> I believe that some small and easy changes would make development of
>> easier for every one:
>>
>> a) the regression system should implement the develop/master branch system
>> which boost libraries do.  This would permit any changes to the regression
>> code and/or anything it depends upon to be tested separately before being
>> unleashed on unsuspecting library developers.
>>
>
> 1. Has there been an instance where the regression system changes failed in
> the current single branch?
> 2. Where would we get the resources to test with more than one branch of
> the regression system?

Do we even have tests to certify that the regression testing system is 
working properly ?

If we do have such tests I do not see why the tests could not be run for 
a 'develop' branch as well as for a 'master' branch, just like any other 
Boost library.

In general I agree with Robert that Boost tools should be tested just 
like any Boost library should be tested, in order to ascertain that any 
changes made to a Boost tool is working properly.

>
> (C)
>
> b) the testing/build components should be tested the same way that boost
>> libraries are tested.  Were this being done, any anomalies on b2 or other
>> components would be detected the moment they occurred so that library
>> developers wouldn't have to spend (a lot) if time tracking them down.
>>
>
> They are currently tested more than most libraries:
>
> https://travis-ci.org/boostorg/build/builds/108576884
> https://travis-ci.org/boostorg/build/builds/85795874
> https://travis-ci.org/boostorg/boost/builds/109532213
> https://travis-ci.org/boostorg/boost/builds/109546290
> http://www.boost.org/development/tests/master/developer/build.html
> http://www.boost.org/development/tests/master/developer/build.html
>
> Is there more testing that should be done?
>
>
>> c) the regression system should be a boost submodule so it gets
>> distributed along whenever one clones the main project.  This would be
>> useful to those who want to understand what's going on and make available
>> the components of the regression system to others which might find them
>> useful. The current system has them in a separate repo which doesn't have a
>> master branch.  I found this to be rather confusing while spending time
>> spelunking into things that are really outside of my responsibility and
>> expertise.
>>
>
> First see (C). Second..
>
> 1. Making it a submodule (as it used to be), adds perceived requirements on
> it that I don't want to keep (as it adds to the time I need to spend in
> dealing with it).

The same applies to all of us. <g>

> 2. It's only slight convenience for a small percentage of Boost developers
> for some small percentage of time.
> 3. It adds unneeded clutter to the Boost releases as it would get included
> in what end users get.

Simply because a library/tool is regression tested does not mean that 
those tests have to be part of an official Boost release. Granted that 
is normally the case but I believe we do have means by which our 
modular-boost source is reduced to a lesser number of files for an 
official Boost release.

>
> d) The regression test matrix is generated by testing the develop branch of
>> each library against the develop branch of other libraries. Currently, the
>> boost library fails to build with the spirit library on the develop branch.
>
>
> Did I miss someone mention this on the dev list with a [spirit] tag?
>
>
>> So all the serialization library tests fail on the test matrix.  I presume
>> that all other tests of libraries on the develop branch which depend upon
>> the serialization library fail because the serialization library won't
>> build on that branch.  As boost get's bigger, this problem get's worse.
>> How can this be acceptable?
>>
>
> It's not acceptable. But given that (A) and (B) also apply to the Spirit
> maintainers it's hard to avoid :-(
>
> I do appreciate all the suggestions I receive to work around specific
>> problems.  But it would save a huge amount of time if the above changes
>> were made so these problems wouldn't come up in the first place.
>> Suggestions a), b) and c) would be easy to implement.  d) is somewhat more
>> challenging - but well worth it.
>
>
> I don't see a suggestion in (d).
>