The Bazel Platform Last updated Mar 24, 2025

Installation? Installation? We don’t need no stinkin’ installation!

Bazel’s package management is very different from opam’s. Installation, deployment, packaging etc. are not directly handled by Bazel. Those capabilities must be supplied by rules, for example rules_pkg.

bazel run can be used to build and run tools.

External aspects use Bazel’s aspect mechanism, which is designed to support the use of external tools (tools not included in the toolchain) to extend build actions throughout a dependency graph defined by the aspect. External aspects specify a set of rule attributes that determine a “shadow” dependency graph, and Bazel will apply the aspect to all the targets in the dependency graph.

The other method, which is not generally recognized, is to use Bazel’s --output_groups facility to enable inline aspects. An inline aspect is a build action that is directly supported by a build rule but only executed when the user requests a specific output group. Inline aspects are local; they do not propagate to additional build targets in the way that

For example, the OCaml SDK includes a tool, ocamlobjinfo, that dumps textual (human-readable) metadata about compiled artifacts to stdout. To use ocamlobjinfo, the developer must first compile the object of interest - say, //foo/bar:A, producing foo/bar/a.cmo - and then run ocamlobjinfo against the output.

Without an inline aspect, this would be impractical for Bazel users. Building a target puts the outputs in a filesystem area controlled by Bazel, on a path constructed by Bazel. So to apply ocamlobjinfo to the output of $ bazel build foo/bar:A, one would have to obtain from Bazel the path of the output object. This is possible, but very cumbersome.

But an inline aspect makes this almost trivial. The ocaml_module rule includes in its implementation function a build action to compile its input. It also includes an inline aspect that runs ocamlobjinfo against output of the compile action. The inline aspect is just a build action that takes the output of the normal compile action as its input, and uses ctx.actions.run_shell to run ocamlobjinfo. (Use of run_shell is required in this case because ocamlobjinfo writes to stdout and does not have a parameter like -o to redirect output to a file.)

What makes this work as an aspect is that the output of the ocamlobinfo action is listed only in the OutputGroupInfo provider, as field modinfo. That means that the aspect action will only be executed if the user passes --output_groups=modinfo to the build command. So a normal $ bazel build foo/bar:A will ignore the inline aspect and proceed as usual. But $ bazel build foo/bar:A --output_groups=modinfo tells bazel that only the output specified as the modinfo field of the OutputGroupInfo provider need be built. Since that field contains the output of the ocamlobjinfo build action, which in turn depends on the output of the compile action, the result is that the target will be compile as normal, and then the ocamlobjinfo action will be run against the compilation output, producing the modinfo requested by the user.

Inline aspects only make sense for actions that use tools provided by the toolchain. An inline action that uses an external tool would make the ruleset dependent on that tool, whether the user wants to use it or not.

The bazel info command will print a dictionary listing the parameters, file locations, etc. that Bazel uses internally. It supports a large number of options; run $ bazel help info to see them all; to see just the keys for the dictionary, run $ bazel help info-keys.

Most of entries in the dictionary, most of the time, can be safely ignored; but if you run into trouble, two of them can be helpful with debugging: command_log and output_base.

Bazel writes logs to a command_log file each time it executes a command; it overwrites the file. You can discover the location of the file by running $ bazel info command_log. Since the output of this command will overwrite the log file, you must use an alias or shell script to enable easy browsing. See the aliases recommendation in OBazl Conventions for an example.

The output_base directory contains a subdirectory, external, that contains the external repositories your project has configured. You can browse the BUILD.bazel files of an external repo, for example, to verify that you are using the correct target labels.

Bazel can print a source text representation of each target :

$ bazel query '@ppx_tools//:*' --output build

This shows what the target looks like to Bazel after it has been processed (e.g. variables expanded, etc.).

A single build target may generate multiple build actions. For example, if an ocaml_module rule is parameterized with a ppx argument, it will generate two actions: one to transform the source file with the PPX, and one to compile the result. Each action will have a command line string.

Normally there is no need to pay these actions any mind, but if something goes wrong with your build it may be useful to see exactly what a build rule is doing - what the actions are, what commands and arguments are used to run the actions, and what the inputs and outputs are. Fortunately this is easy to do. You can use the [action query]() facility to print all the actions generated by a rule without actually running the rule (so it does not trigger any compilation). For example, the following will print all the actions (and much additional information) generated by the //foo/bar:baz target:

See Transparency for more information.

To list all the files in the directory containing associated with a package:

$ bazel query 'kind("source file", @<repo>//<pkg>:*)' --output label_kind

To include all subpackages (subdirectories containing BUILD.bazel file), use @<repo>//<pkg>/...:* instead of @<repo>//<pkg>:*.

E.g.

$ bazel query 'kind("source file", @ppx_tools//:*)' --output label_kind

$ bazel query 'kind("source file", @ppx_tools//metaquot:*)' --output label_kind