Building with Bazel

Episode 10 - Understand Dependencies

While it would be nice to be able to write an app that doesn’t include any external dependencies, it most cases, your apps will include some external code whether produced by outsiders or from other members of your team. Dependency management is core part of Bazel.

Remember, Bazel is designed to be a functional build system. By providing the same inputs to the build system, we’ll always get the same output. This means, it’s critical for us to declare each version. In some cases, such as including external rules, we even provided SHA values to ensure we were dealing with the correct version.

When it comes to Bazel, all our dependencies are declared in the workspace. As know, a workspace can contain at least one or more build. This means that while every dependency is declared in the workspace that not every build file will make use of that dependency.

Later, you’ll see how when you create build targets, those targets will depend on other targets. When declaring those targets, you want the build targets to match the actual depenendcies being used in the code. That is, your build dependency graph should match the actual dependency.

So here we have a NetworkService that depends on a NetworkingLibrary that depends on a JSON encoding and decoding library. This is a direct dependency graph.

Things get complicated when the NetworkService starts using the JSON library in its code, but doesn’t declare its dependency. It all works because the dependency is resolved through the NetworkLibrary.

So if someone removes the dependency from NetworkingLibrary to the encoding and decoding library, the build breaks. By declaring all our dependencies where we are using them, our app becomes resilient to this types of errors.

More importantly, Bazel will be able to analyze the entire build and thus maximize parallel building. This allows builds utilize all the cores on a cpu. This can expand to other developer machines and in fact, it can expand over entire networks. So while it may take quite a bit time to audit your code. Google is well aware of the time investment. In fact, in took them two years to correctly adjust their code that resulted in better code, but more importantly, must faster build times.