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/