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