Re: [boost] Boost Incubator Status Report

Subject: Re: [boost] Boost Incubator Status Report
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-10 07:59:57

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/