Re: The new Boost 17.0.0

From: Matt Borland (matt_at_[hidden])
Date: 2020-11-27 11:49:27

On Fri, 2020-11-27 at 11:58 +0300, Antony Polukhin via Boost wrote:
> == The problem.
> * it is huge, in consists of legacy on more than a half, with a lot
> of
> dependencies between libraries. This is extremely painful for big
> companies, because there's no efficient distributed build system.
> Each
> company invents it's own and/or tries to minimize headers by all
> means.
> 
> == The Solution
> TL;DR: we need a C++17 fork of Boost with close to 0 dependencies
> between libraries and namespace versioning.
> 
> 
> == Action points
> 0) Discuss
> 1) Bury the idea, wait for a few years, goto 0); or make a boost17
> repo with the same layout as the existing one, but without submodules
> 2) start the migration
> 
> --
> Best regards,
> Antony Polukhin
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost

If I may propose another course of action for discussion what about a
Boost 2.0 that is based on the C++20 standard? One of the goals of
modules was to reduce compile times/overhead especially with monolithic
libraries like boost. After a module has been imported one time it
should be nearly free to use thereafter. Clang, GCC, and MSVC all have
experimental support for modules to begin development of Boost 2.0. If
we are truly concerned about adoption in the future I would not expend
significant time and effort to rewrite using what is now a past
language standard, and instead look forward. As for how to execute
this? We could use the python 2/3 model where both are supported with a
published countdown to when new development ceases on the old version.

Matt