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
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
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.