Why generate BUILD files

The work required to run a build for your repository goes through these steps:

1. One-time setup “set-and-forget”, either by running a wizard/installer command or by an expert who has done it before.
2. Write code
3. Add a new dependency - easy path to declare this to the tooling, such as auto-fix builtin to the IDE
4. ~yearly maintenance and deal with churn and upgrades

Typical build systems are setup by an expert, then operated by product engineers. As the DevOps movement brings specialization, these are more often different people with different skill sets.

Why is this easier in other build systems?

• more mature tooling for a product engineer adding dependencies
• coarse-grained dependency graph doesn’t need much editing

Bazel (by itself) is broken

• It forces product engineers to manually express their dependency graph BEFORE invoking bazel.
• BUILD files are in a language called Starlark. Engineers don’t want to learn a new language just to interact with the build tool (even though it’s a Python dialect)
• Unlike alternatives like Buck2, Bazel doesn’t allow a dynamic dependency graph based on file contents. So BUILD generation is needed as a workaround to read file content BEFORE Bazel runs and declare the correct graph.

Next Lesson