Niall Douglas wrote:
I'm not sure I understand. If you prefer not a script-generated boostorg/outcome repo, what do you prefer?
There's script generated within my build system. That's okay, it's already doing that, indeed that's going to get much worse with issue #25.
Then there's script generated whereby a new git repo is one-way synthesised by cron script from another git repo (like ASIO). I'd prefer not to have to do this.
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?