3 ms·

> https://wg21.link/p1689 https://wg21.link/p1689 Ah, that. It's just a new -M output. It's still cannot handle header units though without a major extension t

by boris 3y ago

> https://wg21.link/p1689 https://wg21.link/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/scanDependencies-does-not-take-into-acc/10029154 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.

humanrebar 3y ago
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.

by boris 3y ago

humanrebar 3y ago

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.