Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-24 20:26:14
On 10/24/18 12:12 PM, Niall Douglas via Boost wrote:
I think this question is ill-formed. It presumes that someone (us) can
determine what other people are going to do. No one has the authority
or influence to do that.
But what can we do then. We can provide support for those who want to
restrict their choices of Boost libraries according to their own
criteria. That is:
a) given information about a library, e.g. which level of C++ is
required, is it actively maintained and supported, etc. etc.
b) show me a list of elgible libraries.
c) and tell me if any on that list are dependent upon on non elgible
d) decide which subset of Boost I want to use.
e) download and build that subset. Presumably this subset will be
compatible with each other. Let's call that a "closed compatibility
subset" - or for brevity "closed subset".
Now I can download, build any closed subset that captures the
requirements that I have set. If I'm lazy - and I am - I could use
someone elses prepared list - C++17 compatible libraries. Or C++03
libraries presumable a larger set. If I'm not lazy I might make my own
closes subset - those libraries which don't required RTTI. or ...
In short, rather than having the Boost organization try to make these
subsets for me through some sort of review process, just help me make my
Now implement "modular" boost and we're done. Libraries no longer in
use are siting out there somewhere - but who cares - they're not
polluting anyone's universe. The whole problem just becomes a non
problem. No committees, no discussion, no pain, no deprecation, no
discussions about replication, no boost policy regarding library
support, no discussions about what boost policy regarding library
support. no wasted time - all for the cost of a little bit of "wasted"
disk space. Wouldn't that be heaven?
Now the only thing we need to do to get all of these benefit is to make
it easier to use a subset of the whole of boost. That is Boost
Modularization. In order to do this we need:
a) Consensus that this is necessary and valuable.
b) More detail on what has to be done to achieve this. A
c) Some implementations.
Amazingly, slow progress is being made on all three fronts. I've very
hopeful for the future!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk