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)

Commits related to this issue

Most upvoted comments

@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

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.