From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-07-08 10:57:35
>
> Hi,
>
> C++20 modules seem to be a good tool to improve compile times and to hide
> the implementation details of the libraries.
>
> I've been looking throught the sources of {fmt} library. Looks like the fmt
> library approach to C++20 modularization seems to fit Boost quite well.
I performed an analysis for Boost some months ago. Here is what I found out:
- https://anarthal.github.io/cppblog/modules
- https://anarthal.github.io/cppblog/modules2
And here's the discussion we had on this ML:
- https://listarchives.boost.org/Archives/boost/2024/04/256460.php
- https://listarchives.boost.org/Archives/boost/2024/04/256597.php
TL;DR:
- Modules help build times when parsing dominates. Clean builds don't
gain as much as you'd expect, but re-builds are much faster.
- Mixing #include <std_header> and import std causes errors on most
compilers at the moment (although it should not). We were in contact
with MSVC devs and the fix may take time.
- Distributing modules to users so they can consume them with CMake
isn't trivial. In this sense, Boost is different to fmtlib in that a)
most libs are header-only and b) we have a deep dependency tree (where
fmtlib is a single library).
- Some core maintainers (including Peter Dimov and Rene Rivera)
manifested that the amount of work required to enable modules for core
libraries wasn't worth the effort. Together with point 2 above, this
limits the number of libraries that can be modularized to only the
ones without dependencies (e.g. Boost.Decimal).
I think the biggest challenge in distributing Boost as a module is the
CMake consumption part. Without solving this, we won't get anywhere.
I'm happy to hear your opinion.
Regards,
Ruben.