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:
>>> 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk