Motivation

Stop Starlark flags from propagating to the exec config by default.

i.e. on:

$ bazel build //foo --//my:flag=some_custom_value

stop compilers, code generators, and other tools from also building with --//my:flag=some_custom_value.

The vast majority of the time these settings are intended for production code, not compiler tools. Passing them to tools compromises caching, making builds slower and more resource-heavy for no good reason.

Description

With --incompatible_exclude_starlark_flags_from_exec_config=true, --//my:flag=some_custom_value resets to its default value when building compiler tools, and any other exec-configured targets.

Incompatible Flag

--incompatible_exclude_starlark_flags_from_exec_config

Migration Guide

This only affects you if you need a Starlark flag to pass its value to exec-configured targets.

While this isn't common, there are valid use cases. For example a flag modifying rules_foo behavior may want to apply to all rules_foo targets, no matter their configuration.

To propagate your Skylib or label flag value to the exec config, do:

string_flag(
    name = "myflag",
    build_setting_default = "default_value",
    scope = "universal", # "target" is now the current default
)

If you define your own flag with custom_flag = rule(...), you may need to give it a string-based scope attribute, then do the same.

Alternative:
Set --experimental_propagate_custom_flag=//my:flag (at the command line or in a .bazerlc). This flag can be set multiple times. Try not to rely on this. We'd like to remove this flag in preference for the first option.

In which Bazel LTS version will this incompatible change be enabled?

Bazel 10

TODO List

• Implement Starlark flag propagation API so migration step 1 is viable
• Flip the flag