> Extraordinary claim. If you think this claim is extraordinary and CMake is a counterexample, I don't know what to say. Have you really not have had to manual

> Extraordinary claim. If you think this claim is extraordinary and CMake is a counterexample, I don't know what to say. Have you really not have had to manually fuzz around with stale builds (by e.g. issuing "clean" commands, removing build/ directories etc) when using CMake or had to figure out why something worked on your machine but not a colleagues? > You will need to explain how Bazel does that and, say, CMake + Ninja don't. CMake makes no serious effort at all at "figuring out what has changed". Even trivial stuff doesn't work. If you have a wildcard pattern in a CMake file and you add a file that matches the wildcard, you will generally get a stale result (which is why it's "not recommended"). So not even explicitly specified inputs work correctly and CMake makes no real attempt to to detect unspecified implicit dependencies. Does your CMake build setup correctly detect when you updated gcc or some system library? That some build artifact implicitly depends on another? By contrast Bazel goes through some fair amount of effort not only to detect changes to specified dependencies correctly but also to sandbox build steps to check that they don't depend on stuff that has not been explicitly specified. As the blaze docs say: > When given the same input source code and product configuration, a hermetic build system always returns the same output by isolating the build from changes to the host system. You can get pretty close with bazel; good luck with CMake.