Add placeholder features for toolchain type migrations (#165)

These placeholders can be referenced in rules_cc, rules_java and
rules_python in preparatory commits. When Bazel commits switching the
toolchain types over have landed, a bazel_features version bump can
supply the correct release information for the new location.
1 file changed
tree: 0651a2e08e69c86a6dfb9d896ab64e7a63dda152
  1. .bcr/
  2. .github/
  3. private/
  4. test/
  5. .bazelignore
  6. .bazelrc
  7. .bazelversion
  8. .gitignore
  9. .pre-commit-config.yaml
  10. BUILD.bazel
  11. CONTRIBUTING.md
  12. deps.bzl
  13. features.bzl
  14. LICENSE
  15. MODULE.bazel
  16. README.md
  17. renovate.json
  18. WORKSPACE.bazel
  19. WORKSPACE.bzlmod
README.md

Bazel Features

Use this to determine the availability of a Bazel feature in your ruleset. It works under the hood by comparing the Bazel version against a known range in which the feature is available. Example usage:

load("@bazel_features//:features.bzl", "bazel_features")
if bazel_features.toolchains.has_optional_toolchains:
    # Do something

The features.bzl file contains the list of features.

Accessing globals

References to global Starlark symbols that do not exist cause load time errors, which means that their availability in Bazel cannot be tested via a regular feature. Instead, use bazel_features.globals.<symbol>, which is <symbol> if the symbol is available and None else.

See globals.bzl for the list of symbols that can be checked for in this way.