Bazel has several directory trees that it uses during a build.
The most obvious directory is the source tree where your code lives and where you run your builds. This is, by default, what Bazel uses for source files.
However, you can combine several source trees by using the
--package_path option. This basically overlays them, from Bazel’s point of view. For instance, if you had:
/ home/ user/ gitroot/ my-project/ WORKSPACE BUILD foo/ usr/ local/ other-proj/ WORKSPACE BUILD bar/ BUILD
Then if you ran
bazel build --package_path=/home/user/gitroot/my-project:/usr/local/other-proj //..., Bazel would “see” the directory tree:
WORKSPACE BUILD foo/ bar/ BUILD
If a package is defined in multiple package paths, the first path “wins” (e.g., the top-level package containing foo/ above).
Finally, source code for external repositories is tucked away in Bazel’s output base. You can see it by running:
$ ls $(bazel info output_base)/external
Once bazel figures out what packages a build is going to use, it creates a symlink tree called the execution root, where the build actually happens.* It basically traverses all of the packages it found and comes up with the most efficient way it can to symlink them together. For example, in the directory tree above, you’d end up with:
execroot/ my-project/ WORKSPACE -> /home/user/gitroot/my-project/WORKSPACE BUILD -> /home/user/gitroot/my-project/BUILD foo/ -> /home/user/gitroot/my-project/foo bar/ -> /usr/local/other-proj/bar bazel_tools/ ... # Tools built into the Bazel binary local_config_cc/ ... # C++ compiler tools
You can check out the execution root by running:
$ ls $(bazel info execution_root)
Here’s the * from the execution root section above! If you’re on Linux (and, hopefully, OS X soon), your build actually takes place in a sandbox based on the execution root. All of the files your build needs (and hopefully none it doesn’t) are mounted into their own namespace and executed in a hermetically sealed environment: no network or filesystem access (other than what you specified).
You can see what’s being mounted and where by running Bazel with a couple extra flags:
$ bazel build --sandbox_debug --verbose_failures //...
We’re working on improving how configurable Bazel is, but for years the main configuration options have been the platform you’re building for and what your compiler options were. If you run an optimized build, then a debug build, and then an optimized build again, you’d like your results to be cached from the first run, not overwritten each time. In a somewhat questionable design move, Bazel uses a special set of output directories that are named based on the configuration. So if you build an optimized binary, it’ll create it under execroot/my-project/bazel-out/local-opt/bin/my-binary. If you then build it as a debug binary, it’ll put it under execroot/my-project/bazel-out/local-dbg/bin/my-binary. Then, if you build it optimized again, it’ll be able to switch back to using the local-opt directory. (However, bazel uses symlinks out the wazoo, so I don’t know why it doesn’t use symlinks to track which configuration is being used. Seems like it’d be a lot easier to have the outputs directly under execroot/my-project.)
Also, Bazel distinguishes between files created by genrule and… everything else. Almost all output is under bazel-out/config/bin, but genrules are under bazel-out/config/genfiles.
(I’m kind of bitter about these files, I’ve been working on a change for what feels like months because of this stupid directory structure.)
Note that Bazel symlinks execroot/ws/bazel-out/config/bin to bazel-bin and execroot/ws/bazel-out/config/genfiles to bazel-genfiles. These “convenience symlinks” are the outputs shown at the end of your build.
Suppose you build a binary in your favorite language. When you run that binary, it tries to load a file during runtime. Bazel encourages you to declare these files as runfiles, runtime dependencies of your build. If they change, your binary won’t be recompiled (because they’re runtime, not compile-time dependencies) but they will cause tests to be re-run.
Bazel create a directory for these files as a sibling to your binary: if you build //foo:my-binary, the runfiles will be under bazel-bin/foo/my-binary.runfiles. You can explore the directory or see a list of them all in the runfiles manifest, also a sibling of the binary:
$ cat bazel-bin/foo/my-project.runfiles_manifest
Note that a binary can run files from anywhere on the filesystem (they’re binaries, after all). We just recommend using runfiles so that you can keep them together and express them as build dependencies.