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