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

On 2/16/2016 12:17 PM, Rene Rivera wrote:

On Tue, Feb 16, 2016 at 10:34 AM, Robert Ramey 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).