That's right. However, there are distinct implications on how this dependency graph is constructed, analyzed, and evaluated. "Build Systems à la Carte" (Mokhov, Mitchell, Peyton Jones) [1] goes deeper into formalizing these differences.
[1] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
Make (to use your example) does not do any sandboxing to ensure that the declared dependency graph is actually correct. This is the big innovation in Bazel (and Co).
Electric Make has had sandboxing since 2002, no conversion from your familiar make-based builds to a new shiny build tool required, and it can make on-the-fly corrections to execution order if that sandboxing reveals that incomplete dependency specifications caused something to run in the wrong order (relative to a strictly serial build).
"Sandboxing" in a build tool cannot be claimed as Bazel's innovation.
Can you link to the project?
Sorry for the belated response. Electric Make is part of CloudBees Accelerator: https://www.cloudbees.com/cloudbees-accelerator.
Re:Bazel 1.0
by jburgess777 on Saturday October 19, 2019 @10:56AM
(#21298797)
He was probably talking about a product from Electric Cloud:
Pretty much every other build system (e.g., make) is rooted in having a proper dependency graph. This is not a unique property of Bazel.