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: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-02-16 12:17:55

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?

(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).
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.

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).

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail