incompatible_config_setting_private_default_visibility
See original GitHub issueVisibility on config_setting
isn’t historically enforced. This is purely for legacy reasons. There’s no philosophical reason to distinguish them.
This flag, in conjunction with --incompatible_enforce_config_setting_visibility
(https://github.com/bazelbuild/bazel/issues/12932), removes that distinction.
Values:
--incompatible_config_setting_private_default_visibility=off
: if--incompatible_enforce_config_setting_visibility=off
, every config_setting is visible to every target, regardless of visibility settings. Else, everyconfig_setting
without an explicitvisibility
setting is//visibility:public
(ignoring package visibility defaults)--incompatible_config_setting_private_default_visibility=on
: if--incompatible_enforce_config_setting_visibility=off
, every config_setting is visible to every target, regardless of visibility settings. Else,config_setting
follows the same visibility rules as all other targets.
Incompatibility error:
ERROR: myapp/BUILD:4:1: in config_setting rule //myapp:my_config: target 'myapp:my_config' is not visible from target '//some:other_target. Check the visibility declaration of the former target if you think the dependency is legitimate
Migration:
Treat all config_setting
s as if they follow standard visibility logic at https://docs.bazel.build/versions/master/visibility.html: have them set visibility explicitly if they’ll be used anywhere outside their own package. The ultimate goal of this migration is to fully enforce that expectation.
Issue Analytics
- State:
- Created 3 years ago
- Comments:17 (17 by maintainers)
For tracking: cc @meteorcloudy
Failures: https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/1341
To fix:
As much as I would like to see it in 6.x, I keep seeing rippling churn of updating dependencies.
rules_pkg
was merely the piece that the Bazel team saw. I can easily imagine that kind of problem lurking in any rule set that needs to define a config setting that others reuse.On Fri, Nov 4, 2022 at 12:29 PM Greg @.***> wrote: