Well, the daemon-based approach won't really work with certain kinds of distributed build and caching systems. I suspect it will work for a lot of use cases though. It's also problematic if you want to parse code without a build system as such. Does every analysis tool and IDE need to add support for that GCC specific API?
But the p1689 approach is implemented the same way for all three major compilers. And it should be reasonably adoptable by anything else that might want to work with CMake and other build systems that choose to support p1689.
Ah, that. It's just a new -M output. It's still cannot handle header units though without a major extension to the preprocessor semantics, which so far only Clang managed to implement (for details, see https://developercommunity.visualstudio.com/t/scanDependenci... ; in particular notice how it was reported 1.5 years ago but is still unfixed).
> Does every analysis tool and IDE need to add support for that GCC specific API?
That besides the original point, which was that I claimed build2 supported this since 2021 to which you replied that it couldn't have.
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.
> 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
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.
> given communication APIs for GCC just landed in its main branch a month ago
Can you elaborate on what are these "communication APIs"?