Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-25 01:49:00
On 10/24/18 6:31 PM, Robert Ramey via Boost wrote:
My real point here Nail is that you're conflating two separate issues.
Library development, design, and maintenance with library deployment.
You could relatively easily deploy a "closed" subset of boost which was
"cleaner" or simpler, or whatever just by selection. It would achieve
everything you've wanted to achieve:
a) exclude libraries no longer maintained.
b) exclude libraries which are not compatible with newer libraries (I
don't think any of these exist)
c) exclude libraries which do not provide, in your humble opinion, any
Think bigger. You could create a special deployment of Boost for
students which would a closed subset which one could start to use much
faster than being confronted with the whole of boost and standard library.
Think bigger yet. Create a deployment for beginners in C++. Call it:
"Boost for Dummies"
This may sound funny, but I don't mean it to be. I see the idea of
creating "curated" Boost/C++ deployment as being a really useful and
valuable idea which doesn't require that all the boost "cats" to be
harnessed to the "next big thing" which ain't going to happen.
This single most valuable step to this goal would be to cajole the
maintainers of the libraries to create documents in BoostBook if they
don't already. I don't know how many are left. But that "Might" and
the one's that aren't are likely so old you wouldn't want them in your
"Boost for Dummies" anyway. Boost book can be rendered with great
flexibility and it would be possible to craft a beautiful publication
quality book that would be really useful to a lot of people. I can see
C++/Boost for Dummies
Nial Douglas - Principle Architect of Boost.
So I think I see where you're trying to go with this. And I see the
merit in it. But if you approached in the way I suggest, I think it
might be more likely to get you what you might be seeking.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk