Subject: Re: [boost] Proposal for moving Boost to CMake
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-17 01:47:41
On 16.06.2017 21:26, Robert Ramey via Boost wrote:
> On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:
>> At least that's one dream I keep having...
> This is the vision that I had when I made my proposal at C++Now titled
> Boost 2.0.
> It's also the vision that I had/have in mind when I create the Boost
> Library Incubator.
> I believe the two lines about fleshout the vision you've articulated
> so you've got two votes - (not that it's up for a vote).
That's good to hear (even though it's not up for a vote :-) ).
> My presentation boost 2.0 was probably my least successful ever. I
> lost control of it as it veered into and argument about automatically
> generating dependencies. I was sott of struck by lightning. But still
> it articulated some ideas which have come to fruition such as the
> Boost Library Official Maintainer program and Boost Library Incubator.
It's funny how most discussions here end up as tool discussions. ("When
the only tool you have is a hammer, every problem looks like a nail.")
> They haven't been the total success I would have hoped, but it does
> seem that we have less complaints about lack of library maintenance
> and we are reviewing more libraries which seem better prepared for
> review. Of course maybe it's confirmation bias.
> The last time this was discussed on the list, things circled down the
> drain of automatic dependencies.
> Let's not do this again. Let's just accept that somehow dependencies
> will be figured out, even if it has to be done by hand.
Let's be very conscious about the fact that the problem to solve is not
the technical one (which is the easy part !), but the underlying
systemic (social) one. And until that is being addressed, no tool will
> The more interesting thing is the decoupling. Let each library decide
> which build, test, documentation, deployment, bug tracking system to
> use. The Boost Politburo would set requirements rather than design a
> specific system.
Right. And even those requirements would have to be carefully to be
> Examples would be:
> a) every libary has to have documentation. Documentation has to be
> standards conforming. That is it would have to describe libraries in
> terms of valid expressions rather than implementation
Yes ! (And for avoidance of doubt: "standards conforming" should
exclusively be concerned about the outcome, not the way it is produced
(which is an "implementation").
> b) every library has to have a test suite
> c) every library has to have a single button download, build and test
> d) every library has to use a public version control system for it's
> source code
> e) every library has to use the Boost License
> f) every library has to fulfill a minimum set of directory structure
> f) Review managers cannot accept library into boost if it fails any of
> the above.
Agreed to all of the above.
> Of course the Boost web page would have a portion which looks like the
> Boost library Incubator. So be it. Actually I've even considered
> just adding a page for each current boost library. The library
> dropdown would then specify accepted boost libraries, proposed boost
> libraries, etc.
> Building of all of boost would of just the sequence of "one button"
> download build and test for each library.
> I was going to put this in a separate post by you started down this path.
Thanks for following up. Yes, I think these are good goals. Is there no
way we can build up momentum around these ideas to be able to move into
that direction ? (And again, please let's not focus on any technical
details how we achieve the above, but first and foremost agree where we
want to go.)
I'd be more than willing to help in any way I can. As Boost.Python
maintainer I'm trying to go down that route anyhow. But I would
appreciate company ! ;-)
> Robert Ramey
-- ...ich hab' noch einen Koffer in Berlin...