Re: The new Boost 17.0.0

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-11-27 14:10:18

On 27/11/2020 12:36, Mike via Boost wrote:
>> Gesendet: Freitag, 27. November 2020 um 13:26 Uhr
>> Von: "Niall Douglas via Boost" <boost_at_[hidden]>
>>
>> On 27/11/2020 12:19, Vinnie Falco via Boost wrote:
>>> On Fri, Nov 27, 2020 at 12:58 AM Antony Polukhin via Boost
>>> <boost_at_[hidden]> wrote:
>>>> asio 18 -> 3?
>>>> beast 19 -> 4?
>>>
>>> Beast depends on Asio, so you will have to convince Christopher
>>> Kohlhoff to go along with this idea for Asio.
>>
>> If I were Chris K, I'd respond "If you want to use Boost.ASIO with the
>> standard C++ library, please go use Standalone ASIO. Boost.ASIO is
>> specifically ASIO targeting Boost".
> 
> Whats the problem? Shouldn't that essentially just be a matter of tweaking
> boostify.pl to replace fewer std types from the no-boost reference code
> with boost equivalents than it currently does? Or is there more to it?

Yes, it's support costs for additional build variants.

>From my perspective, I already support an Outcome targeting Boost and an
Outcome targeting the standard library. If somebody else wants to do
more work to support a third build variant, cool. But it won't be me.

(For added information, I know of two forks of Outcome maintained by
others. One didn't like my build system and so completely replaced it;
the other needed to customise Outcome for a proprietary platform to an
extent I wasn't willing to support)

Outcome consumes a fraction of the effort required to support ASIO, and
even then, supporting Outcome has consumed 100% of my non-work free
hours for two weeks now, thanks to Travis requiring replacement with
Github Actions, and just released VS2019.8 ICEing when fed Outcome which
of course produced a bunch of urgent support requests. Sigh.

Niall