[boost] Boost 2.0 ideas (was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's c

Subject: [boost] Boost 2.0 ideas (was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's c
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-05-20 08:25:22

On 19 May 2016 at 8:36, Robert Ramey wrote:

> Given the above, I never understood what you're proposal was (actually 
> is, because I still don't understand it). 

Simplified:

1. New Boost 2.0 distribution with rebooted internals incompatible 
with Boost 1.x. C++ 14 STL used by default.

2. Rebooted internals designed by a committee of the willing and with 
a yay/nay vote of the usership of the final design. No arguments with 
the plan from outside the committee, just yay/nay.

Niall's personal top ten ideas for rebooted internals (committee 
decides after investigation of everyone's proposed options):

1. cmake build system throughout.

2. ctest test system throughout.

3. cdash reporting system throughout.

4. Niall's Boost 1.x compatibility shim layer (which he presented at 
C++ Now 2015) allowing a single source code base to be part of Boost 
1.x and 2.x simultaneously. Library maintainers decide to opt into 
the shim, or not.

(4a. Even if not using compatibility shim, all Boost 2.0 libraries 
version their ABI and API. Some libraries may optionally enforce ABI 
compliance using that tool)

5. New documentation system based on doxygen comments somehow.

6. New online single header generation facility so you tick the Boost 
2.0 libraries you want and it spits out a single drop in header file.

7. Built in edge execution coverage testing and fuzz testing using 
Niall's fancy new LLVM based automated kernel test infrastructure 
he's currently working on for presentation in 2017 (it's not written 
yet, but looking seriously cool).

8. clang AST based enforcement of Boost coding guidelines.

9. All Boost 2.x libraries to be C++ Modules

10. There is no longer any Boost 2.x distribution as a ZIP archive. 
Instead all contributors to Boost 2.x libraries are required to use 
cryptographically signed git commits and tags. We push distribution 
onto the online distro generator and onto github and dispense with 
official releases entirely in favour of cryptographically signed tags 
meaning "this is known to work well" as defined by Travis + Appveyor 
running a deep suite of unit, integration and functional tests.

I have more items if I were to trawl my notes. Those just came to the 
top of my head.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/