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: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-16 11:34:28

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

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.

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.

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.

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.

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

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.

Robert Ramey