| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
HostTransition can't be migrated yet because it depends on
BuildConfiguration.
PiperOrigin-RevId: 180842784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, if the default_value is not set, but the flag
has been given a value by a configuration transition, that value
is used and no error is produced.
If the default_value is not set and the flag has not been given
a value by a configuration transition, the rule produces an
error (as it did before, but now the error is different).
config_feature_flags with default_values behave as they did before.
(use the default value if no configured value is set, otherwise use
the configured value)
Also transition the Optional used in feature flags from Guava to
Java 8.
RELNOTES: config_feature_flag's default_value is optional. It is
only an error to have a config_feature_flag with no default_value
if that config_feature_flag has not been set in the configuration
it is being evaluated in.
PiperOrigin-RevId: 178418907
|
|
|
|
|
|
|
|
|
| |
This requires moving the convenience constructor using RuleConfiguredTarget to be owned by RuleConfiguredTarget.
This refactoring is required by later work to allow SplitTransitionProvider to use configurable attributes. This would require packages/Attribute.java -> analysis/ConfiguredAttributeMapper.java, where in general, the 'analysis' package depends on the 'packages' package. This is the easiest way to prevent a circular dependency.
RELNOTES: None.
PiperOrigin-RevId: 171741620
|
|
|
|
|
|
| |
multiple constraint_values from the same constraint_setting (re: #350)
PiperOrigin-RevId: 169577576
|
|
|
|
|
|
| |
This is on the way to making select() work with constraint_values re: #305.
PiperOrigin-RevId: 169454982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add recursive test_suite rules for all tests that
ci.bazel.io runs for Windows, and set the
top-level test_suite as the CI test target.
Doing so shortens the command line and works
around https://github.com/bazelbuild/bazel/issues/3742
I verified that the old set of tests are the same
as the new set.
Change-Id: Id8d5da3f0c03c9b8969a9f8e1e9a3096888365aa
PiperOrigin-RevId: 169242858
|
|
|
|
|
|
| |
This is a trivial change with a large file footprint.
PiperOrigin-RevId: 169169864
|
|
|
|
| |
PiperOrigin-RevId: 168607439
|
|
|
|
|
|
|
| |
getPotentialSplitTransitions() from FragmentOptions.
RELNOTES: None.
PiperOrigin-RevId: 168218102
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
| |
This will be used to create thin skylark rules to allow for select() on provider values, with xcode_config_alias's XcodeProperties to be the first.
This is demonstrated in XcodeConfigTest.
RELNOTES: None.
PiperOrigin-RevId: 167204266
|
|
|
|
|
|
|
|
| |
This feature is opening up beyond just ConfigFeatureFlags, and so should not
be restricted.
RELNOTES: None.
PiperOrigin-RevId: 167195959
|
|
|
|
|
|
|
|
| |
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. Unfortunately, there are a number of reverse deps
from analysis code to Skylark classes, so moving these is the only way to make
progress.
PiperOrigin-RevId: 164612957
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163343931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the problem that
config_setting(
name = "a_and_b",
values = {
"define": "a=c",
"define": "b=d"
})
doesn't work as expected because BUILD parsing removes duplicate dictionary keys in accordance with Pythonic behavior. Even worse, Skylark will soon enforce this more aggressively by making this an outright error.
This change introduces the define_values attribute:
config_setting(
name = "a_and_b",
values = {
"normal_flag": "normal_value",
},
define_values = {
"a: "c",
"b": "d"
})
This is equivalent to "$ bazel build ... --normal_flag=normal_value --define a=c --define b=d" at the command line.
Also tried to clean up some ConfigSetting naming for clarity around the different kind of flags.
PiperOrigin-RevId: 162627180
|
|
|
|
|
|
|
| |
The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies.
RELNOTES: None.
PiperOrigin-RevId: 162249778
|
|
|
|
|
|
|
|
|
|
| |
OptionMetadataTags.
These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead.
Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category.
PiperOrigin-RevId: 161515674
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 160831413
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It's now easier to customize Printer if in different situations objects should
be printed differently. Also its API is cleaner now. Names of methods of SkylarkValue objects now reflect names of Skylark functions: SkylarkValue#repr and SkylarkPrintableValue#str.
PiperOrigin-RevId: 160635154
|
|
|
|
|
|
|
|
| |
testing.
Unlike in the production flags, these flags are only used for internal testing. Tagged them as NO_OP instead of the default UNKNOWN to make it clear that we do not need these to become properly tagged.
PiperOrigin-RevId: 160526472
|
|
|
|
|
|
|
|
|
| |
This requirement was added to PatchTransition in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc.
This also adds tests for ConfigFeatureFlagTransitionFactory's other
behaviors.
RELNOTES: None.
PiperOrigin-RevId: 158294134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 156979845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was possible to have
//package:foo : barbaz
and
//package:foobar : baz
hash to the same value, making it very easy for users to cause a hash
collision by accident. This adds a zero byte after each string so that the
hash will differentiate the two.
RELNOTES: None.
PiperOrigin-RevId: 156216723
|
|
|
|
|
|
|
|
|
|
|
| |
Because SkylarkClassObject declares equals, hashCode, and toString,
AutoValue doesn't bother creating those, but since these classes didn't
pass any data back to SkylarkClassObject, the defined methods don't work
properly. This shows up as all instances of a class having the same
hashCode and being equals() to each other.
Change-Id: I50734f04369231cd2141dd368b04a3f0997a7d18
PiperOrigin-RevId: 153735995
|
|
|
|
|
|
|
|
|
| |
These are two different concepts. Do not remove category overload compatibility in this CL, to keep this change limited to converting the current uses of category.
With some flyby formatting fixes on affected OptionsBases.
RELNOTES: None.
PiperOrigin-RevId: 153390002
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives the ability to select on config_feature_flags. They still
have not been publicly documented, because there's no way to set them.
But, progress.
config_setting still needs to have either values or flag_values; it cannot
have both be empty. However, values is no longer mandatory, nor must it be
nonempty (as long as flag_values is set nonempty).
RELNOTES: None.
PiperOrigin-RevId: 152515036
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConfigSetting was previously in analysis/config, where it was slightly out
of place (as it is a rule, not an integral part of the analysis backend).
This is also necessary to integrate it with ConfigFeatureFlag, as otherwise
this would be a circular dependency (analysis/config <-> rules/config).
ConfigFeatureFlagRule itself has been moved into ConfigRuleClasses, where
it can use the ConfigBaseRule and the nonconfigurable reason from the other
configuration rules.
RELNOTES: None.
PiperOrigin-RevId: 152275823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This rule allows users to define flags as part of the Bazel configuration.
These flags will be select-able through a new attribute on config_setting,
and settable through transitions within certain special rules.
This rule is currently not supported by any other rules, not even
config_setting, and its values cannot be set; accordingly, it's not very
useful yet.
RELNOTES: None.
PiperOrigin-RevId: 151746523
|
|
This will eventually be used to store the values of user-defined
configuration flags, once such a rule is added. Because this rule
does not exist yet, this fragment is currently not part of the
rule class provider. This will have to be done when that rule
is turned on.
--
PiperOrigin-RevId: 150638292
MOS_MIGRATED_REVID=150638292
|