Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-14 15:13:14

>> Boost-lite provides the cmake based build, config, test, Boost.Test
>> alternative, install, partial preprocess single header include
>> generation and much of the internal implemention classes used by
>> Outcome. However if accepted then Outcome would gain a Boost.Build
>> veneer and be auto generated by script from the standalone Outcome
>> same as Boost.ASIO is, and so I figure none of that is in scope for
>> this review.
> 
> This doesn't exactly inspire confidence.
> 
> When a library enters Boost and is distributed in Boost releases,
> there's no longer any point of it duplicating Boost functionality under
> the hood (without a very good reason); while not requiring Boost is
> understandable for standalone use, in a Boost release Boost is by
> definition already available.

Almost all usage of boost-lite is substitutable by Boost. You can switch
it with a macro. That code path is stale and likely won't work right
now, but it wouldn't take much effort to restore it if the peer review
demanded it. You may remember some years ago I developed a set of
switchable STL implementation bindings to let one switch a library
between Boost or the C++ 11 STL. Outcome uses those.

>> then Outcome would [...] be auto generated by script from the
>> standalone Outcome same as Boost.ASIO is
> 
> carries the unfortunate implication that Outcome in Boost may be,
> similarly to Boost.ASIO, a second-class citizen that may lag behind the
> "real" Outcome where the real development occurs.

This is a chimera.

Standalone ASIO has only diverged significantly from Boost.ASIO because
standalone ASIO has become unstable due to all the changes flowing down
from developing the Networking TS. Chris has, quite rightly, kept
Boost.ASIO insulated from all that profound change. If the Networking TS
were not happening, standalone ASIO and Boost.ASIO would be in sync, and
for the record, if you really want an up to date Boost.ASIO, you can go
run ASIO's Boost.ASIO generation scripts and you'll get one.

Furthermore, Outcome is itself already generated by script. When you
include Outcome, you are including the pregenerated edition. Therefore
generating a "boost flavoured" edition of same is no different.

That means both standalone Outcome and any potential Boost.Outcome are
exactly the same class of citizen, which is to say first class.

> And finally,
> 
>> then Outcome would gain a Boost.Build veneer...
> 
> libraries are much easier to review if they are already in their final
> Boost form, ready to be copied into $BOOST_ROOT/libs/$library. It's
> understandable that people don't want to invest into that final step
> until the library is accepted... but it should also be understandable
> that going that extra mile is a sign of commitment that speaks
> positively about the author and can therefore tilt reviewers toward
> acceptance.

Once again you jump to conclusions.

Outcome is header only and follows the Boost directory layout. You can
drop it into a Boost distro if you really want to, but there is no
point, it makes no use of Boost.

All the conformance unit tests sit in a single file, and because I knew
there would be the above complaint about missing Jamfiles, I made a
shell and batch script that lets you compile the unit tests and run them
without needing cmake. You'll find one for POSIX and one for Windows in
the test directory.

Quite a few libraries submitted to Boost recently came with cmake
instead of Boost.Build. Only after approval did the author make the
Jamfiles. There is precedent here.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/