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

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-20 18:45:20

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?