Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-27 23:04:34

On 5/27/17 3:03 PM, Niall Douglas via Boost wrote:
>>> Some Boost developers are ideologically and irrationally attached to
>>> "how things are done around here", yes.

Boost developers are attached to the current way of doing things.  But 
it's not irrational.

Boost libraries are source code.  The do not (or should not) depend on 
build tools, the particular compiler, the operating system or whatever. 
They might depend on other source code libraries - boost or std.

There is a wide combination of build environments which can incorporate 
this source code. If they follow C++ rules the boost source code can be 
incorporated into the build.

Now it looks like you've injected a dependency going in the other 
direction - that the usage of outcome is dependent upon CMake, Git, Git 
submodules.  Note that this is dependent upon the original dependencies 
of outcome on other boost libraries.  The fact that these dependencies 
are masked by pre-processing just hides this fact.  In boost, if an 
error is detected in config.hpp (for example) any other module which 
depends upon it needs to be re-built this can be done locally if 
desired. That's all.  In your world the the preprocessing has to be 
redone so the user then rebuilt. So the "user" will need the original 
config.hpp anyway.

Of course this applies to boost module which has been "imported" into 
outcome.  If outcome has made it's own substitutes from scratch - like 
in the case of config.hpp - the situation is worse, the maintainer will 
have to maintain something that is repeated in boost.  More work to do.
Since we've now coupled the two tasks in both directions, they have to 
be handled as a pair.  If other libraries were to adopt this approach it 
would be maintenance nightmare.  Just the fact that that it depends on 
bunch of convoluted (git and submodules) and flakey (CMake) tools should 
be a tip off.

I could go on but it's clear I'm not going to convince you this is a bad 
idea.  I get that.

But your major blunder is to try to tail gate a whole new way of doing 
things which was bound to be controversial into boost by attaching to an 
otherwise simple and perhaps useful facility.  It's a pity since with a 
different approach you might have gotten more credibility and success. 
Your idea of addressing the issue of distributing minimal subset of 
boost related to a particular library (or set of libraries) doesn't 
belong here. It's unrelated to outcome, it's a boost-wide issue - not an 
issue with outcome. By conflating these issues and coupling it with your 
code you've made it almost impossible to get any useful part of the 
library accepted.

And it's not because boost developers are ignorant of modern C++. That's 
just wishful thinking on your part.  It's on you because you bad decisions.

Robert Ramey