| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179425421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, every Android-related top-level target will use the feature
flag whitelist, regardless of whether it has any feature flags.
This change makes it so that these targets only load the whitelist if
they need it.
In the process, it moves the value of the whitelist from the attribute
definition method to outside of it. Because it's a builder, this is only
a minor change to each callsite.
RELNOTES: None.
PiperOrigin-RevId: 169405621
|
| |
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this CL, if the feature_flags attribute of android_test or
android_binary is not set, no transition takes place when entering that
rule. This means that if it is depended upon by another test or binary, it
will use the enclosing test or binary's flags.
This permits users of feature flags to depend on non-users of feature flags.
The opposite is still not permitted. If a dep sets feature flags, then the
target depending on it must have the exact same feature flags set.
This way, all targets used in an android_test are built the same way, but
it's possible to interoperate with targets which are agnostic to feature
flags.
Note that "not set" is different from "set to the empty dictionary"; the
former reuses the definitions set higher up in the build graph, while the
latter clears all feature flag values and resets them to their defaults.
RELNOTES: None.
PiperOrigin-RevId: 167035122
|
| |
|
|
|
|
|
|
| |
This migrates the config_feature_flag implementation over and removes the
old flag (which was not used except to test it). Fare thee well, old flag.
RELNOTES: None.
PiperOrigin-RevId: 165995681
|
| |
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries
for analysis, exec, and rules.
PiperOrigin-RevId: 164438390
|
| |
|
|
|
|
|
|
| |
The method is moved to FeaturePolicyConfiguration.java so that it can be used
by unrelated parts of the code using feature policies for whitelisting.
RELNOTES:none
PiperOrigin-RevId: 161648169
|
| |
|
|
|
|
|
|
|
|
| |
To limit rollout of this potentially risky feature, a new policy
is added to the --feature_control_policy feature list. The contents
of the package_group pointed to by that label are then used to control
which targets are allowed to use feature flags and related features.
RELNOTES: None.
PiperOrigin-RevId: 160686186
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aliases mess with the assumption that
attributeValue.containsKey(target.getLabel())
for every target in the prerequisites of a LABEL_KEYED_STRING_DICT
attribute.
The solution is to use AliasProvider.getDependencyLabel(target) instead.
This fixes it for all current users, including SkylarkRuleContext.
This also adjusts config_setting flag_values and Android feature_flags
to do intelligent things with aliases in their respective attributes.
RELNOTES: None.
PiperOrigin-RevId: 157594095
|
|
|
This is the first actual user of the config_feature_flag rule, able to actually
set its value (and thus give a point to using it!)
This feature is not fully launched yet, but it is usable in any build
containing this change.
RELNOTES: None.
PiperOrigin-RevId: 152948153
|
jingwen
mstaib
gregce
ulfjack
plf