On 8 Nov 2014 at 17:01, Robert Ramey wrote:
In my view, the single most effective Boost could do is to raise the standards for documentation of Boost libraries and help library authors meet these standards. This is a primary focus of the Boost Library Incubator. There's one big problem however. There isn't a strong consensus on what high quality C++ library is. I've tried to make the case for my viewpoint in the incubator (Advice, Concepts) And I think this has helped some - but still there are lots of people who I haven't yet been able to sway to my point of view. This is a work in progress.
As probably a leading disagreer with your vision here, I'll just quickly update everyone on how my promised fork of Boost is going. My vision for how to renovate Boost previously explained on this list is that we need a ranked scoreboard of tightly focused domain specific C++ libraries where the ranking is generated by automated scripts which generate some form of quality score. This would eliminate the need for any community reviews, to get your library high into the ranked scoreboard you try your best to game the quality score, and hopefully if the automated scripts are designed right you should get some quality appearing in the resulting library. The hard part is getting between here and there, and for that we need actual truly modular Boost and not somewhat modular Boost only at the git level. To that end, I started some months ago a local bindings tool which uses the clang AST grok library to parse a C++ library and output a set of bindings, plus some preprocessor programming to get the C preprocessor to generate some unique namespacing. All this lets you seamlessly "templatise" the dependent libraries of a library, and moreover different "instantiations" of your library with alternative dependencies can coexist happily in the same Translation Unit (TU). I don't claim this solution is pretty, and it's very heavily dependent on the preprocessor and on the compiler coping with all the symbol aliasing, but it does work. All this is great in theory, so what about practice? Well, two weeks ago I started porting proposed Boost.AFIO from Boost to the local bindings platform. It took about twenty hours of find in files regex find and replace and a lot of work on the config.hpp setup to port the library over, but now it's done AFIO now supports the following configurations, all of which can coexist in the same TU: * AFIO using Boost.Filesystem, Boost.ASIO, Boost.Test and Boost.Build. i.e. the original configuration. * Or, AFIO using any of the following variants in ANY combination: 1. Boost.Filesystem OR Filesystem TR as provided by VS14 CTP 4. 2. Boost.ASIO OR standalone ASIO OR Networking TR. 3. Boost.Test OR CATCH (BindLib provides an emulation of Boost.Test using CATCH). 4. Boost.Build OR 100% header only everything, including dependencies, i.e. NO build system at all. This leads to the neato outcome that on VS14 CTP 4 I can compile the entire of AFIO, including all unit tests, into a single executable with a single cl.exe call on the command line, all without any trace of Boost anywhere on the system. I can then execute all of those unit tests by running the executable, and it "just works". Total conversion time so far: about 30 hours. I would estimate another 30 hours to go, but much of that will go on configuring the Jenkins CI to regularly test every combination of the dependency matrix above. I'll present on all this work at C++ Now, but for now I would claim that namespace binding has finally made dual use Boost libraries very tractable. And with that comes the opportunity for truly modular Boost libraries which are 100% header only and can be distributed as such, and therefore makes possible the ranked scoreboard I want. I think the ability for users to download a single, combined, standalone header file which imposes no ABI consequences, is ABI safe and requires no other dependencies including any choice of build system is *my* vision of what will reinvigorate usage of Boost by developers everywhere. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/