Motivation

If a select is constructed by a macro and refers to fixed targets via label string keys, these labels will be resolved relative to each usage of the select value in a BUILD file. This differs from the behavior of attribute defaults and is a common gotcha - with Bzlmod, how a label resolved crucially relies on the repo it is being resolved from.

Description

With --incompatible_eagerly_resolve_select_keys enabled, select calls from .bzl files will instead resolve label strings in keys relative to the containing .bzl file. This behavior can be matched by explicitly wrapping each key in Label(...) (or str(Label(...)) for compatibility with old versions of Bazel that don't support Label in select keys).

Incompatible Flag

--incompatible_eagerly_resolve_select_keys

Migration Guide

select usages in BUILD files are not affected.

If a macro dynamically constructs select keys that are meant to be evaluated relative to the calling BUILD file, for example because it also instantiates config_settings that it then references in a select, the keys will have to be wrapped in native.package_relative_label(...).

In which Bazel LTS version will this incompatible change be enabled?

Bazel 9

Additional Context

No response

TODO List

No response