bazel: bool_flag in config_setting via alias seems broken
Description of the problem / feature request:
When referencing a bool_flag
in a config_setting
via an alias
indirection, the flag value set on the command line seems to be ignored.
NOTE: it isn’t necessarily only broken for bool_flags
, but that’s just a simple example that illustrate the issue. I suspect other flag types would have the same problem.
Feature requests: what underlying problem are you trying to solve with this feature?
I want to enable some sort of late-binding for enabling/disabling features, in a way that would ‘point’ to different workspaces based on a flag (boolean or otherwise). Since select()
isn’t possible in a WORKSPACE
, it seems that a recommended alternative is to go through a select
, config_setting
+ alias
indirection.
I have tried to simplify my example to a minimum size, so this doesn’t exactly illustrate what I’m trying to archive, but it does illustrate the bug I see when following that approach
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
With the following files, run run_all.sh
which will run 4 builds, one by one, and execute the result, printing feature a: 0
or feature a: 1
depending on the outcome of the select
in the BUILD
file.
As we can see, we get 0
and 1
(depending on the --//:enable_feature_a=xxx
command line option) when the select
is for a config_setting
that references a bool_flag
directly, but we always get 0
regardless of the command line option when using a config_setting
that references a bool_flag
via an alias.
❯ cat WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "bazel_skylib",
urls = [
"https://github.com/bazelbuild/bazel-skylib/releases/download/1.0.3/bazel-skylib-1.0.3.tar.gz",
"https://mirror.bazel.build/github.com/bazelbuild/bazel-skylib/releases/download/1.0.3/bazel-skylib-1.0.3.tar.gz",
],
sha256 = "1c531376ac7e5a180e0237938a2536de0c54d93f5c278634818e0efc952dd56c",
)
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()
❯ cat BUILD
load("@bazel_skylib//rules:common_settings.bzl", "bool_flag")
config_setting(
name = "feature_a_enabled",
flag_values = {
":enable_feature_a": "true"
}
)
config_setting(
name = "feature_a_enabled_aliased",
flag_values = {
":enable_feature_a_aliased": "true"
}
)
bool_flag(
name = "enable_feature_a",
build_setting_default = False,
)
alias(
name = "enable_feature_a_aliased",
actual = "enable_feature_a"
)
cc_binary(
name = "my_binary",
srcs = ["main.c"] + select({
":feature_a_enabled": ["feature_a.c"],
"//conditions:default": ["default_a.c"]
})
)
cc_binary(
name = "my_binary_aliased",
srcs = ["main.c"] + select({
":feature_a_enabled_aliased": ["feature_a.c"],
"//conditions:default": ["default_a.c"]
})
)
❯ cat main.c
#include <stdio.h>
extern int get_feature_a_value(void);
int main(int argc, char** argv) {
printf("feature a: %d\n", get_feature_a_value());
}
❯ cat feature_a.c
int get_feature_a_value(void) {
return 1;
}
❯ cat default_a.c
int get_feature_a_value(void) {
return 0;
}
❯ cat run_all.sh
bazel build --//:enable_feature_a=false :my_binary
bazel-bin/my_binary
bazel build --//:enable_feature_a=true :my_binary
bazel-bin/my_binary
bazel build --//:enable_feature_a=false :my_binary_aliased
bazel-bin/my_binary_aliased
bazel build --//:enable_feature_a=true :my_binary_aliased
bazel-bin/my_binary_aliased
What operating system are you running Bazel on?
macOS Big Sur 11.3.1
What’s the output of bazel info release
?
release 4.0.0
Have you found anything relevant by searching the web?
Looked online, couldn’t find anything.
The original reference to using alias
with select
when selecting things in a WORKSPACE was found here:
https://docs.bazel.build/versions/master/configurable-attributes.html
(see “Why doesn’t select() work with bind()?”)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 22 (12 by maintainers)
@brentleyjones I don’t think so, unless @meteorcloudy pushes hard for it. 7.0.1 is to fix serious regressions that slipped through into 7.0.0 and this doesn’t look like one.
@iancha1992 Candidate for 7.0.1?
@bazel-io fork 7.1.0
@bazel-io flag
I have an internal change out to fix this. Hilariously, @jin just started working on this 2.5 years old bug the exact moment I did 😦
Hi @gregestren, I take a look at this over the week and let you know if this is something I can handle. As I look through this ticket, I’ll add any questions I have on this thread.