glob(allow_empty=False) evaluated unconditionally; cannot be guarded by select #25361
Labels
team-Configurability
platforms, toolchains, cquery, select(), config transitions
team-Core
Skyframe, bazel query, BEP, options parsing, bazelrc
team-Documentation
Documentation improvements that cannot be directly linked to other team labels
team-Loading-API
BUILD file and macro processing: labels, package(), visibility, glob
type: bug
untriaged
Description of the bug:
BUILD files'
glob
expressions seem to be evaluated unconditionally, preventing users fromselect
ing between differentglob
patterns based on a build condition. In light of the--incompatible_disallow_empty_glob
flag flip, builds may now error when ostensibly inapplicableglob
s don't match anything.In our case, we have instances where we choose between glob patterns based on the host operating system. (Our case involves repository rules, where the outputs fetched by the repo rule impl may vary by platform.) As a result of the flag flip, I'll need to scrub all instances of
glob
and inject anallow_empty=True
as needed, which can be misleading to users/readers. (That said, I totally agree w/ the flag flip. We really would likeallow_empty=False
to be the default.)If this is working as intended, then I'd like to suggest this become a documentation bug. (If that's the case, then my gut feeling is that this limitation should be noted at https://bazel.build/rules/lib/globals/build#glob .)
Which category does this issue belong to?
Core, Configurability, Loading API, Documentation
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Example from Linux or macOS:
Commenting out the
@platforms//os:windows
condition, which should be a no-op when invoked on Linux/macOS, yields a successful build.Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?release 8.1.0 or development version (see above)
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: