Subject: Re: [boost] [modularization] proposal and poll
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-01 06:17:17
Niall Douglas wrote:
> Robert, I think you are under a misapprehension about what I mean by
> "fork". By a fork, I mean forking just a very small part of existing
> Boost, namely whatever minimal support is necessary to start from
> scratch with a new *empty* set of C++ 14 only Boost libraries.
To be honest I think Robert is right that forking is not necessary,
even if it is a small subset of all libraries, and in particular I'm a bit
sceptical that starting from scratch in any way would be a good idea.
Evolutionary changes, of the type that I propose and of the type that
Robert proposes, seem much more productive to me.
> I don't propose to port *any* of the legacy Boost libraries
> whatsoever, they stay where there are. If their maintainers - or a
> sponsor - are willing to do:
> 1. Make their library entirely C++ 11/14 STL based, porting only the
> absolute minimum of old Boost.
> 2. C++ Modules ready i.e. restructured and reorganised to properly
> fit C++ Modules.
> 3. Contribute any general utility code to the core utilities library,
> not duplicating any functionality there, and in a form suitable for
> entering the C++ 17 STL.
> 4. Meet the raised unit test and CI soak test and sanitiser/valgrind
While such changes might have value, they take much more work in
a much more intrusive way than the more evolutionary type of
proposal. I think Robert would be right to expect that few library
maintainers will be willing to participate in such work.
> Then they have a good chance of their library appearing highly ranked
> in the list of C++ 14 Boost libraries, where that ranking is
> generated by a set of clang AST analysers.
> Does this make sense? I am specifically advocating a structural
> break, a clean start. I think working on a fresh, empty Boost will
> get people to volunteer to give up family time to write Boost code
> again. Right now with the present situation there are few incentives
> to sacrifice family time. That needs to change for Boost to survive,
> else the continuing slow decline will continue.
I don't think Boost is dying. I think with time, the changes you propose
will happen anyway (except for the fork), one library at a time.
> On 29 May 2014 at 17:52, Robert Ramey wrote:
>>>> I think it may be easier for the steering committee to justify any
>>>> decision on this proposal,
>> The steering committee doesn't have anything to decide here. The
>> "Proposal" is:
>> 1. Reduction of dependencies between Boost libraries.
>> It's not clear what action is being proposed - but I'm pretty sure
>> the steering committee won't be doing it.
For clarity, I was not proposing that the steering committee would do
the work. Rather, I was proposing that the steering committee would
endorse the work (i.e., make it an official plan) so that dependency
reduction will be considered a joint goal of all library maintainers as
well as anyone willing to do pull requests. Stephen Kelly would take
an advisory role in this project, which includes doing suggestions for
>> 2. Simple but effective automation of dependency handling.
>> I'm pretty sure the steering committee won't be doing this either.
>> If anyone believes that they can implement "simple and
>> effective" automation of dependency handling - just go ahead
>> and do it and let us see it.
I have said I'm willing to do this. I'm not doing it *yet* simply because
(1) I don't currently have the time (but I do want to create time for it)
and (2) I believe it will be more worthwhile if most libraries do not
depend on half of Boost.
>>> Decisive and immediate action on this is vital if Boost is to
>>> survive. I vote yes to both, ASAP.
>> LOL - There is wide agreement that boost has growing pains and
>> will have to evolve. But I haven't seen any proposals for
>> "Decisive and Immediate" which would do anything but make
>> things worse.
Please explain to me and the rest of the list how what I proposed would
make things worse.
>> And since you've got me started - Here is what boost needs go to the next
>> a) Make the review process more effective and efficient - we're taking real
>> practical action to address this now. The jury is still out regarding the
>> effectiveness of our efforts - but we ARE actually doing something.
>> b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11
>> and C++14. Our infrastructure doesn't explicitly address this. The
>> needs to change
>> 1) for each library we need to explicitly state somewhere what
>> version(s) of C++ the
>> library is meant to support.
>> 2) support running of tests and builds for only those platforms.
>> I've suggested that we enhance B2 to address this. So far
>> no one has responded to this suggestion
I have been on a Boost hiatus between December and May, so that may
explain why I missed your suggestion. I highly approve of it. By the way,
since you are keen to take into account the "who": did your suggestion
address who should execute the idea?
>> Note that this would have he effect of encouraging libraries to evolve
>> to later versions of C++ with minimal disruption to both library
>> authors and users.
>> c) Decouple Deployment of Boost Libraries from the Certification
>> of boost libraries. Beman has noted that what he would like to
>> see is something like CYGWIN whereby one specifies what one
>> want's and somehow automagically you get that plush what you
>> need. I realize that this is more or less what is being suggested here.
>> But no one has presented credible proposal for making it it happen.
Maybe I can convince you if I implement the scripts that I have in mind.
>> This would also address the issue of "old" libraries. As they
>> fall into disuse are become superseded by newer ones, the can
>> still be in boost even though their frequency of deployment drops off.
>> The above constitutes a real path forward. This is what Boost
>> needs for the next 15 years.
>> Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk