3 ms·

> So far, CMake 3.28 (still a Release Candidate at time of writing) is the only build system that implements dependency scanning and the ability to consume exte

• humanrebar 3y ago
  There's no way build2 did exactly this back in 2021 given communication APIs for GCC just landed in its main branch a month ago. Clang and GCC, only a year ago or so. How does build2 understand module dependencies without that?
  • boris 3y ago
    build2 use the module mapper API which was available long before 2021: https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper... You can try the examples here https://github.com/build2/cxx20-modules-examples/ https://github.com/build2/cxx20-modules-examples/ with GCC 13 or 12 to confirm, if you wish. > given communication APIs for GCC just landed in its main branch a month ago Can you elaborate on what are these "communication APIs"?
    • humanrebar 3y ago
      https://wg21.link/p1689 https://wg21.link/p1689 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.
      • 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