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