Niall Douglas wrote:
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. 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. It's not possible to have foreign submodules in a Boost distribution, so the choice there would be to either not provide the non-preprocessed form at all, or provide it in a non-functional form. 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 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. That is, outcome.hpp in the Boost distro should compile and work in non-preprocessed form. This - makes it possible to follow the implementation in non-obscured form, - makes it immediately visible what Outcome's implementation detail dependencies are, - makes it possible for people to fix issues in Outcome and give you pull requests against the input from which the preprocessed form is generated, rather than patching the preprocessed header, - avoids potential copyright/license issues with incorporating foreign (non-boostorg) code via a script
Actually there is overwhelming evidence that Boost **users** do not want a dependency on Boost. But I've been saying that for years now.
Yes, and I already answered it, with your swiftly proceeding to ignore my answer. Probably because you didn't understand it, which of course means it's irrational. To repeat, it's not possible for a Boost user to not want a dependency on Boost. A Boost user already has Boost. This is tautological. Not wanting a dependency on "Boost" is characteristic for people who want to use a specific Boost library without any of the rest. This is not the same thing, and it does not at all describe all Boost users, so taking this (existing and legitimate) subset and talking about them as Boost **users** is simply disingenuous. You might note that I'm not one who is a fan of intra-Boost dependencies. You also might recall that I led an effort to eradicate many of the unnecessary ones, have often expressed an opinion that Boost should move in a direction of being less monolithic, and have done quite a bit of work to that effect. Nevertheless, things are what they are, and misrepresenting the actually existing state of affairs does not do service to anyone. The fact remains that (a) close integration between Boost libraries has its benefits to users and (b) a substantial portion of Boost users are not bothered by the downsides of this integration. By all means make Outcome independent of any other Boost libraries - depending on any isn't a requirement for acceptance, and many Boost libraries do try to be reasonably self-contained (*) - but do recognize that this move is not unquestionably without downsides. (*) At one point in the past - the not very recent past - I had shared_ptr.hpp compiling with an empty boost/config.hpp, because there was significant demand from people to use it without anything else from Boost. This demand subsided rapidly however once Boost took off. Nowadays, the majority of Boost users do have Boost.