Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-27 22:03:31

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