| commit | 57ba042a6d2cf548cb5cc8163066262fbd1f8c52 | [log] [tgz] |
|---|---|---|
| author | Alex Eagle <alex@aspect.dev> | Wed Jun 25 07:57:36 2025 -0600 |
| committer | Alex Eagle <alex@aspect.dev> | Wed Jun 25 07:57:36 2025 -0600 |
| tree | 832affd219440eb8aaf1a0b539e9c5b4a12bca18 | |
| parent | edb2a6968327df2dedc275391fff6cf443742812 [diff] |
feat: expose bazel_version It's a fair amount of code that wires up the version here. See https://github.com/bazelbuild/bazel/issues/8305#issuecomment-1954690199 for a published workaround, but it's not complete due to subtleties like https://github.com/bazel-contrib/bazel_features/issues/25 In my opinion the maintenance burden of bazel_features exposing this one string is worth it to avoid other rules like bazelrc-preset.bzl having to copy dozens of lines of code.
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.
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.