| > modules-linearise-the-build-graph problem Modules don't linearise the build graph. Any independent modules are compiled in parallel, but dependents will wait for these modules to be compiled. In fact the problem is the other way round: header-translation unit compilation does a ton of unnecessary repetitive copy-pasting and parsing in the name of achieving embarrassingly parallel compilation. IMO modules help express build and API dependencies clearer, and even despite the so-called loss of parallelisation, build times with modules are generally an order of magnitude faster. An extreme example is Vulkan-Hpp, which has a module interface file[1], and header files that exceed 150K lines of code, cumulatively. Using these headers means even a simple example takes something like 20+ seconds to compile every time. This is even worse when using complicated standard headers like `<algorithm>`, `<functional>`, `<ranges>`, etc. On the other hand, using the module, the compile only takes as long the first time, and every subsequent compile is lightning-quick. [1]: https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/vulkan/... |
There are of course alternatives to header only libraries so there's a sense in which this is a solution to a problem that didn't need to exist in the first place.
But yes, header only libraries are an important solution to the problem of cmake, and modules can patch around the compile time implications of header only libraries, so that's sort of all good.