Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glob(allow_empty=False) evaluated unconditionally; cannot be guarded by select #25361

Open
rbeasley-avgo opened this issue Feb 22, 2025 · 0 comments
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

Comments

@rbeasley-avgo
Copy link

Description of the bug:

BUILD files' glob expressions seem to be evaluated unconditionally, preventing users from selecting between different glob patterns based on a build condition. In light of the --incompatible_disallow_empty_glob flag flip, builds may now error when ostensibly inapplicable globs 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 an allow_empty=True as needed, which can be misleading to users/readers. (That said, I totally agree w/ the flag flip. We really would like allow_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:

$ touch MODULE.bazel
$ cat >BUILD.bazel <<"EOF"
genrule(
  name = "demo",
  outs = ["demo.out"],
  srcs = select({
    "@platforms//os:windows": glob(["*.windows"]),
    "//conditions:default": glob(["*.bazel"]),
  }),
  cmd = "echo $(SRCS); touch $@",
)
EOF
$ bazelisk build :demo
...
ERROR: Traceback (most recent call last):
        File "/.../BUILD.bazel", line 5, column 35, in <toplevel>
                "@platforms//os:windows": glob(["*.windows"]),
Error in glob: glob pattern '*.windows' didn't match anything, but allow_empty is set to False (the default value of allow_empty can be set with --incompatible_disallow_empty_glob).
$ USE_BAZEL_VERSION=last_green bazelisk --output_user_root=$XDG_CACHE_HOME/bazel build :demo
2025/02/21 17:13:57 Using unreleased version at commit 80a9971055c90670effbf4f1fec53347bd0f0e86
2025/02/21 17:13:57 Downloading https://storage.googleapis.com/bazel-builds/artifacts/centos7/80a9971055c90670effbf4f1fec53347bd0f0e86/bazel...
Extracting Bazel installation...
Starting local Bazel server (no_version) and connecting to it...
INFO: Invocation ID: a33f1811-b015-49bd-8e70-6ce480274903
ERROR: Traceback (most recent call last):
        File "/.../BUILD.bazel", line 5, column 35, in <toplevel>
                "@platforms//os:windows": glob(["*.windows"]),
Error in glob: glob pattern '*.windows' didn't match anything, but allow_empty is set to False (the default value of allow_empty can be set with --incompatible_disallow_empty_glob).

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 returns development 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

@satyanandak satyanandak added 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 labels Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

4 participants