Some Boost developers are ideologically and irrationally attached to "how things are done around here", yes.
Saying that is a good indicator that you simply don't understand the objections, so you label them irrational.
It's actually not about objections. It's about ignorance of how the C++ world has moved on since C++ 11 landed. Some here don't care that the C++ world is now overwhelmingly cmake based, and tight coupling into a huge monolith of unnecessary library dependency is just not acceptable for a modern C++ 11 or 14 library.
Take for example the preprocessed outcome_v1_0.hpp header. You think that the objection is that it's preprocessed. Not in the slightest.
The objection is that the non-preprocessed form, which is more convenient when one needs to look at the implementation, study how it's organized, fix a problem one's having (on mignw64, for instance), then prepare a pull request, does not compile unless one has a foreign submodule installed, which in turn picks up two more, even more foreign, submodules.
Most of the world using git has no problems with git submodules. The continuing refusal by some here to invest the effort in understanding modern tooling, and instead blame that tooling for not working the way they'd prefer, is the real source of objection. Away from here in the wider C++ world, nobody appears to have any problem forming a pull request on github which modifies a submodule. It's simply not a problem elsewhere.
In addition, having the preprocessed form automatically generated from whatever's needed from boost-lite (1) obscures which specific parts of boost-lite are used and (2) makes it possible for later versions to pick up other parts of boost-lite.
The partially preprocessed edition reduces compile times for end users. It can be disabled easily using a macro. End users don't care how the internals hang together. They do care about reduced compile times.
The objection - no, the requirement for acceptance - here is not "do not generate a preprocessed form of Outcome." The requirement is that everything necessary for Outcome to compile and work in non-preprocessed form should be part of the Outcome directory in $BOOST_ROOT/libs/outcome, without any foreign repositories being incorporated there by reference.
There is no such requirement for acceptance. Internal standalone utility libraries have a long history in Boost. If their use doesn't affect the end user experience, the choice to use internal standalone libraries is not relevant for acceptance.
That is, outcome.hpp in the Boost distro should compile and work in non-preprocessed form.
It does work in non-preprocessed form. Just update the git submodules after checkout as the git documentation itself tells you to do, and everybody should be doing after a git checkout anyway for any project. If people use git as git is documented, Outcome works perfectly fine in non-preprocessed form. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/