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
> on March 2. That's not a lot of time, please make sure any big work is
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk