On 28/05/2017 00:04, Robert Ramey via Boost wrote:
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.
I have repeated myself several times now on this. End users can include the outcome header and get to work. No cmake, git, or anything else.
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.
I agreed well into last week to replace the extensive preprocessor metaprogramming with a template based solution. I don't see why people are still going on about this. I heard that people don't like the preprocessor work. I agreed to replace it. It's no longer a thing.
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.
Well, an ad hominem attack had to happen at some point. Let me firstly defend boost-lite, or rather the common support code currently called boost-lite but will be renamed at some point. It is quite frankly an amazing solution to the common framework and support needs of C++ 14 libraries. It lets new library authors get up and running with a new library very quickly, implementing best current practice build, packaging, test, dashboarding, version management and lots more without library developers having to think about any of that. It is free of legacy baggage, and saves me on a daily basis a ton load of time and hassle even amongst the three of my libraries it is used in. It also can scale out to an arbitrarily high number of libraries in a decentralised collection, far more incidentally than Boost could ever dream of precisely because of its decentralised design. I am proud of its design, the fact it confounds so many experts who study how it works is testament to the breath of fresh air it bring to modern C++ library design. I don't claim it to be perfect, it suffers particularly from immaturity, and hence I don't recommend that anyone else use it yet. But rather than attack it because it's different, you really should study it and learn from it because it has a lot of really great ideas and implementation in there. It could become the base of a major leap forward in standards aspiring C++ 14 and C++ 17 libraries precisely because we can finally dispense with the whole "one code silo to rule them all" philosophy. But let's return now to Outcome, as that's what this review is about. What happens if Outcome is accepted into Boost in a non-Boost flavoured form, as indeed it has been presented for review? I have already covered this in this review before, but let me repeat one solution of many possible: 1. boost-lite is an excellent neighbour to all other C++ libraries, including different versions of itself. It is benign to include into any translation unit under any circumstances. 2. As Outcome was accepted in std-flavoured form, I would eliminate the namespace bind technology from boost-lite to allow switching between the C++ 11 STL and the Boost STL. I would have deleted it last year except that I wasn't sure if you guys would demand a Boost flavoured library or not. 3. If the Boost release and package managers felt that git sub-submodule support was not going to be allowed, I would use __has_include (which works on all the compilers Outcome works on) to have Outcome probe for a checked out internal edition of the boost-lite git submodule. If not found, it would fall back to Boost.Config, Boost.Stacktrace etc for those parts, and rely on a local copy of some boost-lite support files for the rest. 4. I now have a single git repo which works well standalone and within Boost. I am happy, Boost is happy, Boost users are happy. Let's all dance. As I have said repeatedly during this week, these are all packaging and process problems. They are inconsequential to acceptance or rejection of this library. I am sorry you don't see it that way Robert, but quite frankly, your opinion has no technical basis in fact. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/