I still don't understand. Let me describe what I would like to see, and you'll tell me if you see things the same way.
What I'd prefer to see is, in boostorg/outcome:include/boost/outcome, in addition to the outcome_v1.0.hpp header as currently generated, an outcome.hpp file that includes the headers in v1.0, as it currently does when BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE is defined. I also would like this to work without boost-lite, pcpp, gsl-lite being present at all in the boostorg/outcome repo (or on the user's system).
Furthermore, when someone issues a pull request against boostorg/outcome:include/boost/outcome/v1.0/something.hpp, I'd like to see this pull request kicking off a travis build as we're now used to, with this travis build actually testing Outcome with the pull request applied.
Does this make sense?
I appreciate your wishes in the above. I should point out that Outcome already is tested per commit by Travis and Appveyor, and it keeps a history at CDash: http://my.cdash.org/index.php?project=Boost.Outcome But it is very hard for me to be more concrete at the present time. Most of the dependency of Outcome on boost-lite is soft, e.g. BOOSTLITE_CONSTEXPR <=> BOOST_CXX14_CONSTEXPR, Boost-lite lightweight unit test <=> Boost.Test and so on. But some, especially error_code_extended's use of boost-lite's ringbuffer_log is hard. If reviewers want what I've done to achieve error_code_extended's static storage removed entirely, that would remove much of the hard dependency on boost-lite and a macro layer could rebind the boost-lite macros etc to Boost ones. In this situation, boost-lite goes away in the boostorg repo, otherwise the repos look identical. If on the other hand people like the static storage, one would really rather keep boost-lite in the Outcome repo because bug fixes to there fix lots of other libraries too, and ringbuffer_log is very heavily used by all my libraries. I being the person with the maintenance load here will do whatever I think makes my life easiest. How the library is internally organised I don't think a concern for the end user unless it negatively affects them. Similarly, if people like the cmake build with all the fancy stuff like automatic C++ Modules, you need boost-lite in there for that. If Boost.Build is felt sufficient, then you don't need it. Again, I'd emphasise that boost-lite has no interaction with Boost or any other code. It is a 100% ideal C++ 14 citizen, right down to ABI permuting to ensure mixed versions do not collide. Nobody will ever need to care it's there under the bonnet as an internal helper library. And finally, I do intend to keep Outcome working completely independent of Boost. The vast majority of my user base explicitly do not want a Boost dependency. You'll have noticed the same with Hana. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/