aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/config
Commit message (Collapse)AuthorAge
* Stop allowing generic LateBoundDefault value types. Such types are always ↵Gravatar janakr2018-02-02
| | | | | | | | either a Label or a List<Label>. We can easily enforce this through static type checking, so do it. This will help with LateBoundDefault serialization, since we don't have to serialize an arbitrary object. PiperOrigin-RevId: 184347100
* Allows @AutoCodec to use factory methods.Gravatar shahan2018-01-29
| | | | | | Generalizes @AutoCodec.Constructor to @AutoCodec.Instantiator. PiperOrigin-RevId: 183702768
* Codecs for all non-test Fragment subclasses (except CppConfiguration, ↵Gravatar shahan2018-01-05
| | | | | | handled separately). PiperOrigin-RevId: 180974083
* Move PatchTransition and kin to analysis.config.transitions.Gravatar gregce2018-01-04
| | | | | | | HostTransition can't be migrated yet because it depends on BuildConfiguration. PiperOrigin-RevId: 180842784
* ObjectCodecs for all non-test FragmentOption subclasses.Gravatar Googler2017-12-27
| | | | PiperOrigin-RevId: 180202221
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
* Make config_feature_flag's default_value optional.Gravatar mstaib2017-12-08
| | | | | | | | | | | | | | | | | | | | | | | 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
* Move BazelRuleClassProvider.CONFIG_RULES to its own class in the config package.Gravatar lpino2017-11-30
| | | | PiperOrigin-RevId: 177447905
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* PiperOrigin-RevId: 172480513Gravatar juliexxia2017-10-18
|
* Add more thorough error reporting behavior for when config_setting has ↵Gravatar juliexxia2017-09-22
| | | | | | multiple constraint_values from the same constraint_setting (re: #350) PiperOrigin-RevId: 169577576
* Allow config_settings to match on constraint_values to a target_platform. ↵Gravatar juliexxia2017-09-21
| | | | | | This is on the way to making select() work with constraint_values re: #305. PiperOrigin-RevId: 169454982
* Add a constraint_values attribute and a target platforms attribute to the ↵Gravatar juliexxia2017-09-21
| | | | | | | | configsetting rule class. This is a step in the process of integrating platforms with selects and works towards fixing #350. Also allow the host platform to be empty/nullable to support clients without access to its default settings. PiperOrigin-RevId: 169436155
* Only load the whitelist for Android targets if they use feature flags.Gravatar mstaib2017-09-21
| | | | | | | | | | | | | | 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
* Move RuleConfiguredTarget to lib.analysis.configuredtargets.Gravatar gregce2017-09-19
| | | | | | This is a trivial change with a large file footprint. PiperOrigin-RevId: 169169864
* Remove outdated defaultsToSelf.Gravatar gregce2017-09-12
| | | | | | Part of the static config cleanup effort. PiperOrigin-RevId: 168270713
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | 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
* Expose ConfigFeatureFlagProvider to skylarkGravatar cparsons2017-09-01
| | | | | | | | 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
* Release config_setting.flag_values from the whitelist.Gravatar mstaib2017-09-01
| | | | | | | | This feature is opening up beyond just ConfigFeatureFlags, and so should not be restricted. RELNOTES: None. PiperOrigin-RevId: 167195959
* android_test binary_under_test/deps must have the same flags if any are set.Gravatar mstaib2017-08-31
| | | | | | | | | | | | | | | | | | | | | | 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
* In the config_setting arguments section, the description of the "values" arg ↵Gravatar juliexxia2017-08-29
| | | | | | | states that "This and *values* cannot both be empty" with the word *values* hyperlinking to define_values. Assuming typo(?) and changing to "This and *define_values* cannot both be empty." RELNOTES: None. PiperOrigin-RevId: 166723373
* Split Info into SkylarkInfo and NativeInfo.Gravatar dslomov2017-08-22
| | | | | | | | Prerequisite to implementing shape-declaration and shape-sharing for declared providers, and cleaning up NativeInfo interface. RELNOTES: None. PiperOrigin-RevId: 166057070
* Remove FeaturePolicyConfiguration et al. in favor of the new Whitelisting.Gravatar mstaib2017-08-22
| | | | | | | | 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
* Remove unnecessary options parser caching.Gravatar ccalvarin2017-08-18
| | | | | | | The options parser already has a static cache of all the reflection work performed. There can still be costs associated with the obtaining and combining of options classes (see the BlazeCommandDispatcher's additional caching), but in this case, each parser is made with a single options class, and none of the class-name extraction was being cached, so I think there was nothing gained. RELNOTES: None. PiperOrigin-RevId: 165613107
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Move AliasProvider to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164438390
* Better names for declared providers-related classes.Gravatar dslomov2017-08-01
| | | | | | | | Follows https://docs.google.com/document/d/1aAIVWvHPERDz2cv_PCFGwr8dvh5FcAkENFoRsNS4clk/. RELNOTES: None. PiperOrigin-RevId: 163728291
* Support multiple --define's in config_setting.Gravatar gregce2017-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Clean up ConfigFeatureFlagProvider.Gravatar mstaib2017-07-19
| | | | | | | | | | | | Restrict visibility of the Skylark constructor to the package, which is still necessary because ConfigSkylarkCommon exposes it, otherwise it would be private. It matters less now that these providers are type-safe, but it's still slightly cleaner. RELNOTES: None. PiperOrigin-RevId: 162367759
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | 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
* Moves printing method for feature accessibility errors.Gravatar plf2017-07-12
| | | | | | | | 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
* ConfigFeatureFlagProvider should be declared provider only.Gravatar dslomov2017-07-11
| | | | | RELNOTES: None. PiperOrigin-RevId: 161535034
* Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵Gravatar ccalvarin2017-07-11
| | | | | | | | | | 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
* Make native declared providers type-safe.Gravatar dslomov2017-07-10
| | | | | RELNOTES: None. PiperOrigin-RevId: 161395570
* Enable --feature_control_policy policy for feature flag usage.Gravatar mstaib2017-07-03
| | | | | | | | | | 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
* Refactor PrinterGravatar vladmos2017-07-03
| | | | | | | 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
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Add the default category and tag to all options.Gravatar ccalvarin2017-06-28
| | | | | | | | Move the default from the annotation to every mention. This makes the incompleteness explicit. Will add the defaults to test targets in a separate change. Once all dependencies are cleaned up, the Option annotation will no longer allow options without the documentationCategory or effectTag, to prevent new options being added without categories while we migrate to the new option categorization. PiperOrigin-RevId: 160281252
* Fix ConfigFeatureFlagTransitionFactory to obey PatchTransition equality.Gravatar mstaib2017-06-08
| | | | | | | | | This requirement was added to PatchTransition in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc. This also adds tests for ConfigFeatureFlagTransitionFactory's other behaviors. RELNOTES: None. PiperOrigin-RevId: 158294134
* Fix aliases for users of label-keyed string dicts.Gravatar mstaib2017-06-01
| | | | | | | | | | | | | | | | | 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
* Fix minor hashing bug in config_feature_flag configuration name.Gravatar mstaib2017-05-17
| | | | | | | | | | | | | | | | | 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
* AutoValue and SkylarkClassObject interact badly, so remove that.Gravatar John Cater2017-04-24
| | | | | | | | | | | 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
* Split out option usage restriction from option category.Gravatar ccalvarin2017-04-18
| | | | | | | | | 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
* Add feature_flags attribute to Android binary rules.Gravatar mstaib2017-04-13
| | | | | | | | | | | 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
* Add flag_values attribute to config_setting.Gravatar mstaib2017-04-10
| | | | | | | | | | | | | 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
* Move ConfigSetting into rules/config.Gravatar mstaib2017-04-06
| | | | | | | | | | | | | | | 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
* Add the config_feature_flag rule.Gravatar mstaib2017-03-31
| | | | | | | | | | | | | | 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
* Define the ConfigFeatureFlagConfiguration fragment.Gravatar Michael Staib2017-03-21
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 08:38:01 +0000