5 ms·

I still think the p1689 is a more robust implementation, but I'll stand corrected on the technical details of the build2 implementation of modules. Viable desi

I still think the p1689 is a more robust implementation, but I'll stand corrected on the technical details of the build2 implementation of modules. Viable designs to support header units was still up in the air until six months ago or so. I don't see significant investment for that happening in GCC or Clang still, especially with respect to how build systems are supposed to understand how to invalidate BMIs and such. Current trajectory is that we'll consider header units a niche technology or even an unfinished idea.

boris 3y ago
> I'll stand corrected on the technical details of the build2 implementation of modules. Thank you. > I still think the p1689 is a more robust implementation I agree prescan has advantages, like being easier to integrate into existing build systems/analyzers/IDEs, but robustness is definitely not one of them. What can be more robust than the compiler asking the build system directly during compilation for the information it needs? Compared to the prescan, where the build system first scans the world with one set of command lines, digests the dependencies, and then starts invoking the compiler with another set of command lines. Also, the mapper approach could be used to address other long-standing issues, like proper generated header support: https://wg21.link/P1842R0 https://wg21.link/P1842R0
- humanrebar 3y ago
  Again, the build system and compiler are often on different systems. The design has a specific drawback in that respect. Even for machine local caching, there are advantages to having the communication with the compiler be unidirectional.