> basically the only general purpose build systems out there that even attempt to do the basic tasks of a build system, namely actually figuring out what has changed and needs to be rebuilt.
Extraordinary claim. You will need to explain how Bazel does that and, say, CMake + Ninja don't.
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.
I might have to make clean with CMake after a distro compiler upgrade where the compiler is behind the same symlink or something, dunno, I don't really remember doing that. Otherwise, no make clean because I understand how CMake works. Really, I do. Including with generated code and all that. Wildcards in CMakeLists.txt are misuse.
System libraries are intentionally disregarded as possibly changed dependencies, that is a design decision that most build systems make. System libraries are not supposed to change in binary incompatible ways without a major version upgrade.
Your last point is about reproducible builds, which is a different topic.
Even [task](https://github.com/go-task/task) (a tiny task-runner tool) does that... I don't know any build system that doesn't.
Perhaps the OP means full incremental compilation, which requires "cooperation" from the compilers, really (or the build tool actually parsing the language's AST like Gradle does, I believe). Or in the case of Bazel, the build author explicitly explaining to the build what the fine-grained dependencies are (I don't use Bazel so I may be wrong, happy to be corrected).
Make, cmake, cargo and npm are all examples of popular build tools that require you to manually "clean" to correct build problems. Make and cmake pretty much all the time, IME, cargo less so, but it happens. Bazel/Blaze and derivatives basically don't.
Extraordinary claim. You will need to explain how Bazel does that and, say, CMake + Ninja don't.