[PATCH] D136496: [bazel] Make labels to third-party dependencies explicit

Aaron Siddhartha Mondal via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 19 09:15:02 PDT 2023

aaronmondal added a comment.

> The tricky bit is just that for the caching to be effective it needs to be from a sufficiently similar software environment.

Yes, that's tricky. Since Bazel doesn't track it's external dependencies in the same way that it tracks labels, we wrap the entire Bazel process in a reproducible environment via nix. That environement is fairly straigthforward to convert into a reproducible toolchain container that can then be used by CI runs. It also double-acts as development environment, similar to a docker environment or a python venv. Our current setup works roughly like this:

- Wrap Bazel <https://github.com/eomii/rules_ll/blob/main/bazel-wrapper/default.nix> with the paths from dependencies outside of Bazel's build graph
- Create a toolchain container <https://github.com/eomii/rules_ll/blob/main/rbe/image.nix> that uses that Bazel
- Use that toolchain container to generate remote-execution toolchains. Here <https://github.com/eomii/rules_ll/blob/0167527667dc6c1228164ac98b50772735efeac8/rbe/default/cc/BUILD#L94> is an example of a generated toolchain config.
- *All* build invocations, including local ones then use that RBE-compatible toolchain. If a user's local environment deviates in just a single tool, the build will fail (or at least not use the same cache). This prevents wrong cache use/reuse that would occur when e.g. using just a path like `/usr/bin/clang`.

> Who is "we" in this case? If it's a company, it seems doable to have your own GCS (or whatever) remote cache and make everybody + CI use the same configuration. A world-usable one probably requires more thought.

We use that "everyone has the same configuration" approach internally at the moment, but my intention with this is indeed to create a world-cache that's more or less accessible to everyone. The nixpkgs repository actually does just that, but on a package-level - it's a gigantic cache of reproducible build artifacts that makes it quite simple to customize specific dependencies, but reuse all unaffected ones. Pretty much a coarser-grained version of a Bazel cache. I want the same thing on a fine-grained, incremental-build level.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list