Google Git
Sign in
bazel / bazel / 2768a642420cfd7a17f8c55784a35c7d3b6e9fcc
commit2768a642420cfd7a17f8c55784a35c7d3b6e9fcc[log] [tgz]
authorwyv <wyv@google.com>Wed Sep 15 05:42:01 2021 -0700
committerCopybara-Service <copybara-worker@google.com>Wed Sep 15 05:43:17 2021 -0700
tree4bd2aee216f4ea432155d80c45add641fdaa5888
parent72caead7b428fd50164079956ec368fc54a9567c [diff]
bzlmod: Module extension eval
===================

(https://github.com/bazelbuild/bazel/issues/13316)

* `ModuleExtensionResolutionFunction` (`MERF`) is responsible for triggering all module extension evaluations.
  * It's requested by `BzlmodRepoRuleFunction` (to fetch repos generated by module extensions) and `RepositoryMappingFunction` (to calculate repo mappings for such repos).
* `SingleExtensionEvalFunction` (`SEEF`) is where the bulk of the logic happens. It loads the .bzl file where the module extension lives, and runs the implementation function of the module extension.
  * It stores a `ModuleExtensionEvalStarlarkThreadContext` into the evaluating Starlark thread. This context information is read during the evaluation of the implementation function, and causes the behavior of a repo rule call to differ from when it's called during WORKSPACE evaluation.
* `SingleExtensionUsagesFunction` (`SEUF`) collects all the usage instances of a single module extension and stores it in a SkyValue.
  * It's requested by `SEEF`. The reason that `SEEF` can't request usage information directly from `BazelModuleResolutionValue` is that we don't want any unrelated change in the dependency graph to trigger a re-evaluation of all module extensions. By separating the inputs of each `SEEF` into a separate SkyValue, we utilize change pruning to minimize re-evaluation.

PiperOrigin-RevId: 396814992
28 files changed
tree: 4bd2aee216f4ea432155d80c45add641fdaa5888
  1. .bazelci/
  2. examples/
  3. scripts/
  4. site/
  5. src/
  6. third_party/
  7. tools/
  8. .bazelrc
  9. .gitattributes
  10. .gitignore
  11. AUTHORS
  12. BUILD
  13. CHANGELOG.md
  14. CODE_OF_CONDUCT.md
  15. CODEBASE.md
  16. CODEOWNERS
  17. combine_distfiles.py
  18. combine_distfiles_to_tar.sh
  19. compile.sh
  20. CONTRIBUTING.md
  21. CONTRIBUTORS
  22. distdir.bzl
  23. distdir_deps.bzl
  24. ISSUE_TEMPLATE.md
  25. LICENSE
  26. README.md
  27. SECURITY.md
  28. WORKSPACE
README.md

Bazel

{Fast, Correct} - Choose two

Build and test software of any size, quickly and reliably.

  • Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.

  • One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.

  • Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.

  • Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.

Getting Started

Documentation

Reporting a Vulnerability

To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Contributing to Bazel

See CONTRIBUTING.md

Build status