bazelbuild
Unexpected results with select that mixes config_setting_group and config_setting
Description of the bug:
A select with some labels that refer to a config_setting_group and some labels that refer to a config_setting seems to never resolve to the config_setting_group, even when the same condition matches in other selects.
If Bazel considers such a combination ambiguous, it should say so. Although this behavior happens even in situations where I would consider the config_setting_group an unambiguous specialization.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
BUILD.bazel
load("@bazel_skylib//lib:selects.bzl", "selects")
config_setting(
name = "fastbuild",
values = {"compilation_mode": "fastbuild"},
)
selects.config_setting_group(
name = "mac_fastbuild",
match_all = [
":fastbuild",
"@platforms//os:osx",
],
)
sh_binary(
name = "test",
srcs = ["test.sh"],
args = select({
":mac_fastbuild": ["mac_fastbuild"],
}) + select({
":mac_fastbuild": ["mac_fastbuild"],
":fastbuild": ["fastbuild"],
}),
)
test.sh:
echo "$@"
On macOS, the expected output of bazel run test is "mac_fastbuild mac_fastbuild". But the actual result is "mac_fastbuild fastbuild".
Which operating system are you running Bazel on?
macOS
What is the output of bazel info release?
release 5.2.0
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 master; git rev-parse HEAD ?
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
@jfirebaugh The way config_setting_group is currently implemented such that at the top level analysis, Bazel is not seeing different things in config_setting_group for specialization resolution to happen so the behavior you’re seeing is actually as intended. The original design for config_setting_group is meant for AND_ing and OR_ing config settings only. Although to be fair, it was not clear in the documentation/design doc that the above use case is not supported. Can your use case be satisfied by having a config_setting that is an actual ambiguous specialization of fastbuild?
There are two action items we can both take:
- I’ll update the doc to document to clarify the behavior for
config_setting_group - If you really this specific functionality and there is not any other work around, please feel free to start a design proposal for a patch to
config_setting_grouplibrary and we could go from there.
I have a workaround, so (1) is fine with me. Although I would also propose that if it's intended that this configuration does not work in the way that I believe most users would expect, it should be made to produce a runtime error.
Hello. I work with @jfirebaugh and have run into this issue again in a different context. Is there any update on a solution? This behavior is quite unexpected
