Re: [boost] [1.61] Two weeks remaining for new libraries and breaking changes

Subject: Re: [boost] [1.61] Two weeks remaining for new libraries and breaking changes
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-11 12:49:52

On 2/10/16 10:25 PM, Vladimir Prus wrote:
>
> I wanted to remind that the master branch is closing for new libraries
> and breaking
> changes on Feb 24, about two weeks from now. We'll be closed for major
> changes
> on March 2. That's not a lot of time, please make sure any big work is
> completed.
>
> Thanks,
>

I've been trying for weeks to get tests to pass on develop branch so I 
can merge them in to the master. These changes were intended for 1.60 
but I wasn't able to get this done in time.  So I started way early to 
avoid this problem for 1.61.  But I'm hung up on a few issues with the 
build system.

a) Current status is that I can pass all my tests on my local machine - 
Mac OSX when building static libraries. But now - due to a change from 
an "upgrade" to El Capitan - boost build won't build and run tests for 
shared libraries on this plaform.

b) I've got some issues with function visibility which are visible on 
the test matrix.  Unfortunately, I can't see the error messages because 
they are truncated on the on line test matrix.  They are truncated due 
to the fact that on the compilers in question there is a long list of 
warnings from other libraries - like spirit.  The online display of the 
test matrix needs to elminate the truncation of these error messages.

c) stuck by the above, I cloned boost to my old XP laptop.  This is and 
iffy operation due to some issues related to connectivity, timeouts, etc.

d) I did manage to get past c).  I followed the instructions "getting 
started" to use cygwin.  I use cygwin because I prefer the unix shell 
and the cygwin tests are failing on the online test matrix.

e) I tried to run and build library_status, etc.  but found that it 
wasn't there.  Turns out that this is in a separate repo - regression. 
I can't imagine with that would be the case but there it is.  And it 
also seems that it only has a develop branch but no master branch. 
Again, I can't imagine why anyone would want to do this in the context 
of the boost library conventions.

f) So I build library status from the regression - turns out that it's 
changed and has new documentation.  This expands it's original 
functionality by having it call b2 as a sub process. This is so that 
that one doesn't have to use some sort of script to run the three 
programs which are used to build the local test matrix.  It also means 
you can't run them one by one in an obvious way.

g) attempting to move forward, I just invoke the command suggested by 
the documentation and I can't get it to work.  Looks like 
process_jam_log suffers from some sort of similar affliction. Maybe if I 
spent more time fussing with it ... - but got to keep moving on.

h) So I drop back and just run b2 which which fails due to some issue 
related to unix vs windows directory names.  A little back and forth 
with Steven result in isolation of the problem in b2 build which he adds 
on his list of things to do.  He suggests trying to build b2 with 
windows rather than cygwin gcc as as workaround.  This doesn't seem to 
resolve the problem.

So I'm stuck unless I want to dive in a lot deeper which I don't really 
have the time to do.  This stuff should be easier - but it keeps getting 
harder and harder.

I'm not fingering anyone specific - it's just that what seems are 
isolated problems associated with corner cases add up to major pain for 
other people trying to use software.  One thing that I think would be 
helpful would be for the regression directory to be:

a) included when one clones modularized boost
b) include both develop and master branches
c) have develop branch tested before being merged into the master branch.

In other words, boost tools should be subjected to the same regimen that 
our libraries are.  We should be eating our dog food.

Robert Ramey