For packages, you download things by specifying an archive (zip file, git repo, etc), and a SHA256 hash. Think of it as extremely-precise version pinning. You can also refer to other Bazel projects and use their internal rules if permitted.
The biggest advantages of Bazel over something like CMake are:
1) It is very general, so you can easily express dependencies of this sort:
- concat three text files, then
- run them through a parser generator, then
- use the generated parser in a C library, then
- use that C library in a Go server library and a Rust client library, then
- package the Go server into a Docker container and build an iOS binary that uses the Rust client
This is a cross-language dependency chain that also runs a few Unix tools. In this example, if you edit the Rust client, only the Rust library and the iOS client will be rebuilt. If you edit one of the text files that compose the grammar, everything will get rebuilt.
The dependencies are also a DAG, so if your projects have a shared Go library and you change that, the Go server would get rebuilt, as would the Docker container.
While all this might seem distressingly general, it removes the need for things like "bootstrap.sh" files, "build.rs" files, and all of the unstated dependencies they entail.
2) If you download all of the toolchains (C++, Java, Rust, Go, etc), it's impossible to have "works on my machine" problems. Exceptions are use of "local_*" rules, and Apple binaries (you need machine-local SDKs).
3) This allows great caching. You can run the equivalent of ccache for all of this stuff, locally or shared on a LAN. RBE is even more advanced.
Make cannot guarantee that this is the case. Bazel sandboxs all builds and hides them from non-reproducable things (internet, files they shouldn't get to see, etc) to make it "impossible" for you to have a build that isn't specified correctly in the DAG
Bazel's dependency graph tends to be much more detailed than Makefiles, extends all the way to toolchains at the base, and all the way up to build products and test results.
It can also be composed together across huge file layouts in ways make doesn't support.
The biggest advantages of Bazel over something like CMake are:
1) It is very general, so you can easily express dependencies of this sort:
- concat three text files, then
- run them through a parser generator, then
- use the generated parser in a C library, then
- use that C library in a Go server library and a Rust client library, then
- package the Go server into a Docker container and build an iOS binary that uses the Rust client
This is a cross-language dependency chain that also runs a few Unix tools. In this example, if you edit the Rust client, only the Rust library and the iOS client will be rebuilt. If you edit one of the text files that compose the grammar, everything will get rebuilt.
The dependencies are also a DAG, so if your projects have a shared Go library and you change that, the Go server would get rebuilt, as would the Docker container.
While all this might seem distressingly general, it removes the need for things like "bootstrap.sh" files, "build.rs" files, and all of the unstated dependencies they entail.
2) If you download all of the toolchains (C++, Java, Rust, Go, etc), it's impossible to have "works on my machine" problems. Exceptions are use of "local_*" rules, and Apple binaries (you need machine-local SDKs).
3) This allows great caching. You can run the equivalent of ccache for all of this stuff, locally or shared on a LAN. RBE is even more advanced.