aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/config
Commit message (Collapse)AuthorAge
* Remove --experimental_dynamic_configs=off.Gravatar gregce2017-08-10
| | | | | | | | | | | | This is the first in a series of changes stripping out Bazel's static configuration code. This change removes the ability to request static configurations but not the (now orphaned) logic behind them. Because that logic is all over the code base, it will be removed in layers in followup changes. PiperOrigin-RevId: 164769846
* Move most test options from BuildConfiguration to TestConfiguration.Gravatar tomlu2017-08-07
| | | | | | --test_env isn't moved in this CL since it's exposed to Skylark via BuildConfiguration, making it a somewhat riskier refactor. PiperOrigin-RevId: 164266168
* Add --windows_exe_launcher optionGravatar Yun Peng2017-08-04
| | | | | | | | | | | | | If this is enabled, Bazel will build a Windows native exe binary launcher for sh_binary, in the future this flag will also apply to py_binary and java_binary. By default, it's turned ON, set --windows_exe_launcher=0 to turn it off. Fix https://github.com/bazelbuild/bazel/issues/3491 Change-Id: Ic55bff745670446e585e3cc62af9dc6561527d4f PiperOrigin-RevId: 164234552
* Break out --test_filter into a test configuration fragment.Gravatar tomlu2017-08-03
| | | | | | The other test configuration options will follow in subsequent CLs to keep size manageable. PiperOrigin-RevId: 164068510
* Copy build_python_zip and enable_runfiles flags to the host config.Gravatar philwo2017-07-28
| | | | | | Fixes a bug where the flags would be ignored during Bazel's compile.sh bootstrap. PiperOrigin-RevId: 163341779
* Exclude test/java/ in instrumentation_filter defaultGravatar Googler2017-07-27
| | | | | | | | The computed default used in bazel coverage excludes both javatests/ and test/java. Having the stated default exclude only one of those is needlessly confusing. (Even though in practice that static default will rarely be used.) Also updates the comment about the computed default, since that logic has moved. PiperOrigin-RevId: 163325837
* Define an outgoing rule transition interface.Gravatar gregce2017-07-27
| | | | | | | | | | This lets a parent choose a transition for its dep based on the dep's rule class. Implement (experimental) dynamic Android resource filtering trimming with this. PiperOrigin-RevId: 163259052
* Remove --experimental_dynamic_configs=notrim_partial.Gravatar gregce2017-07-26
| | | | | | Part of the static configuration removal cleanup. PiperOrigin-RevId: 163130922
* 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
* Add --toolchain_resolution_override to allow specifying the toolchain for a ↵Gravatar John Cater2017-07-21
| | | | | | | | | given type. Fixes https://github.com/katre/bazel/issues/6. Change-Id: I6c6e303384277b013bdc27eb80743aa51f2fb98a PiperOrigin-RevId: 162618674
* Deprecate dynamic config OFF and NOTRIM_PARTIAL modes.Gravatar gregce2017-07-20
| | | | | | | | | | | | | --experimental_dynamic_configs=off --experimental_dynamic_configs=notrim_partial are now aliases for --experimental_dynamic_configs=notrim (the default). Also remove outdated --nodistinct_host_configuration warning. PiperOrigin-RevId: 162549307
* Add an undocumented option to remove the separation between the bin and ↵Gravatar lberki2017-07-18
| | | | | | | genfiles directories. RELNOTES: None. PiperOrigin-RevId: 162325236
* 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
* Reserve certain action mnemonics so they can't be used from Skylark.Gravatar tomlu2017-07-17
| | | | | | | If a reserved mnemonic is used, it is mangled. RELNOTES: PiperOrigin-RevId: 161970885
* Remove Java 7 type inference workarounds and TODOsGravatar brandjon2017-07-12
| | | | | | | Found by searching for TODOs mentioning "Java 7". There are plenty of other instances where we can simplify, but I don't want to be responsible for a large blast radius. At least in these cases we're fixing outdated comments. RELNOTES: None PiperOrigin-RevId: 161570189
* 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
* BuildEventWithConfiguration: represent configurations as BuildEventGravatar Klaus Aehlig2017-07-11
| | | | | | | | | | | From a BEP point of view, the only interface of a configuration we care about is its BuildEvent structure. Represent it as such, so that we can move this class to the rest of the buildeventstream module. This is a prerequisite for ActionOwners refering to configurations in the BEP. Change-Id: I6d1c1bf2951aac91607e83cad664553cd6620df8 PiperOrigin-RevId: 161510049
* Remove dynamic configs dep on the static transition table.Gravatar gregce2017-07-11
| | | | PiperOrigin-RevId: 161432622
* Cache flaky tests (remove the cachable flag from test result data)Gravatar ulfjack2017-07-07
| | | | | | | | | | | | | | | | | | | The cachable flag was only set to false for flaky tests. Before this CL, we did not cache flaky tests on subsequent runs, instead rerunning them, even though this is both very expensive and inconsistent with our normal handling, which is to cache passes but not errors. If cache_test_results is enabled, we now also cached timed out test results. If cache_test_results=auto (the default), we now also cache flaky tests. We still do not cache failed tests; the TestRunnerAction checks if the previous test result was marked as passed (which also applies to flaky tests, but not to failed or timed-out tests). Also add some unit tests. PiperOrigin-RevId: 161187950
* Replace Transitions.configurationHook with equivalent rule class transitions.Gravatar gregce2017-07-07
| | | | | | | This removes the last dynamic dependency on the static configuration transition table. PiperOrigin-RevId: 161162272
* Remove FragmentOptions' addAllLabels and getAllLabels and friends.Gravatar mstaib2017-07-07
| | | | | | | | These are now dead code - configuration dependencies are loaded by Skyframe and do not need to be listed ahead of time - and were only ever used in tests. PiperOrigin-RevId: 161146721
* Factor out BuildConfigurationCollection.Transitions.getDynamicTransition.Gravatar gregce2017-07-07
| | | | | | | | | | | | This is a legacy dependency on the configuration transition table, which is only needed for static configurations. Dynamic configurations didn't actually use anything in that table: this was just a convenience interface that could have equally been defined somewhere else. So this cl defines it somewhere else. There's still one last dependency: Transitions.configurationHook. We'll tackle that in a followup cl. PiperOrigin-RevId: 161141650
* Add a default for defaultsToSelf so dynamic transitions don't have to worry ↵Gravatar gregce2017-07-06
| | | | | | | | | | about it. This is only required because PatchTransition extends Attribute.Transition, which requires it. But it's only used for static configurations. So PatchTransition's implicit requirement is pointless and confusing. PiperOrigin-RevId: 161005131
* Add new flag defining an environment group for automatic cpu-based environmentGravatar jcater2017-07-03
| | | | | | detection. PiperOrigin-RevId: 160686932
* Add ActionEnvironment, which is a wrapper class for a fixed+inherited envGravatar ulfjack2017-06-28
| | | | | | | | | | | | | | | | We are currently tracking the action environment (computed from --action_env), and the test action environment (computed from --test_env, and not including the action env) as two pairs of fields, and a lot of callers haven't been updated to handle both parts (TestRunnerAction does, but many 'normal' actions don't). However, both parts have always both be handled, and moving them into a single abstraction makes it harder to accidentally miss one part. We'll subsequently need to update all the action implementations to use the new abstraction, and also update the Skylark API (or bypass it and always apply the action environment for all actions, except we don't know which configuration to use). PiperOrigin-RevId: 160386181
* 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 the converter type for several build configuration options which take listsGravatar jcater2017-06-13
| | | | | | | | of labels. Also fix an indent error in BuildTool. PiperOrigin-RevId: 158747039
* Move InvocationPolicy to the options parser package.Gravatar ccalvarin2017-06-09
| | | | | | | | | | | | | | It was originally included in runtime due to external dependencies, and a desire to keep the options parser a general options library. These dependencies have been or will be removed, and there are plenty of other general flag libraries. InvocationPolicy is fundamentally acting on the properties of this specific OptionsParser and needs proper access to it for the proper solution to a number of existing bugs, which means having access to things that should be package private. PiperOrigin-RevId: 158523111
* Automated g4 rollforward of commit e7ab452ac940e645046221dee9b63a670f8a276c.Gravatar gregce2017-06-09
| | | | | | | | | | | | | | | | | | | | | | (Automated g4 rollback of commit 23004957a56d304106d5dbf0d6ea52ec10713b39). *** Reason for rollback *** The problems that forced commit 23004957a56d304106d5dbf0d6ea52ec10713b39 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc. *** Original change description *** Automated g4 rollback of commit e7ab452ac940e645046221dee9b63a670f8a276c. *** Reason for rollback *** Some of the work supporting this is being rolled back due to uncaught crash bugs. *** Original change description *** Enable dynamic configurations for all builds. PiperOrigin-RevId: 158420321
* Track the test environment in Skyframe, like the action environmentGravatar ulfjack2017-06-09
| | | | | | | | Instead of passing a client env into the test strategies, use the same mechansim as --action_env, by depending on the right set of Skyframe nodes that correspond to client env entries. PiperOrigin-RevId: 158401670
* Fix automatic host platform detection to check the --host_cpu flag.Gravatar John Cater2017-06-06
| | | | | | | | | Also adds a new target_platform attribute that checks the --cpu flag. Part of #2219. Change-Id: Icc732917db127ac8377a7722adc70b1a722d538a PiperOrigin-RevId: 158143095
* Automated g4 rollforward of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar gregce2017-06-05
| | | | | | | | | | | | | | | | | | | | | | | | (Automated g4 rollback of commit de92f9d8ea093416fae999073bbfcf3cf501ab55). *** Reason for rollback *** The problems that forced commit de92f9d8ea093416fae999073bbfcf3cf501ab55 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc . *** Original change description being rolled forward *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely.... *** ROLLBACK_OF=156180015 PiperOrigin-RevId: 157865224
* Add .equals(), .hashCode() to EnableLipoTransition.Gravatar gregce2017-06-02
| | | | | | | | | | | | This fixes a subtle integration bug between PatchTransition, ConfiguredTargetFunction, and DependencyResolver. Short story: ConfiguredTargetFunction.getDynamicConfigurations assumes at most one <Attribute, Label, Transition> entry per configured target dep. DependencyResolver.dependentNodeMap faithfully supplies this by returning an OrderedSetMultimap<Attribute, Dependency>, where each Dependency is a <Label, Transition>. OrderedSetMultimap guarantees no <key, value> repeats, but if you have two semantically equal EnableLipoTransition instances that don't satisfy .equals(), deduping fails. Most PatchTransitions don't have this problem because they're singletons. But each EnableLipoTransition is instantiated with a Rule, so singletons don't work here. This problem can only happen when a rule has multiple instances of the same C++ dep under the same attribute. But this isn't actually possible for normal attributes like "deps" because they don't allow duplicates (see RuleClass#checkForDuplicateLabels). Only non-LABEL_LIST attributes can trigger this. PiperOrigin-RevId: 157733284
* BEP: also report make variablesGravatar Klaus Aehlig2017-05-29
| | | | | | | | | An important part of a configuration are the "make variables", containing values such as TARGET_CPU. Report them as part of the description of the configuration. Change-Id: Id918cc340acac87cf95cc66581345f8060cb4877 PiperOrigin-RevId: 157378950
* Use FeatureConfiguration to compute value of CC_FLAGS make variableGravatar hlopko2017-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | This cl introduces new action_config type for Crosstool named 'generic'. This can be used to set the value of CC_FLAGS make variable using much more expressive mechanism (action_configs + features) than previous make_variable Crosstool messages. This has been requested by the C++ LPT. However, as FeatureConfiguration needs RuleContext, CC_FLAGS cannot be computed using configuration only anymore. Also, FeatureConfiguration is C++ rules specific class, and Bazel build-base cannot depend on it. Therefore we cannot use FeatureConfiguration for ExtraActions, for example. Because it cannot be made perfect, this cl is not updating all the possible places that expand make variables but limits the scope to: * genrule (the only widely used rule that often expands make variables) * *_test (CC_FLAGS is used by Tensorflow in the 'args' attribute) * cc_rules (people sometimes set 'copts' to something like: "-DCC_STRING=\\\"$(CC)\\\" -DCC_FLAGS_STRING=\"$(CC_FLAGS)\"" The long term plan is to use Skylark C++ API to get C++ command lines, so CC_FLAGS together with this inconsistent solution will be removed. RELNOTES: CC_FLAGS can be defined using 'generic' action_config in CROSSTOOL PiperOrigin-RevId: 157202883
* Automated g4 rollback of commit c4134802dd15d6ef5cca6521f6bf6aac395ee2ad.Gravatar kchodorow2017-05-23
| | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Roll forward of directory name change *** Original change description *** Automated g4 rollback of commit 1d9e1ac90197b1d3d7b137ba3c1ada67bb9ba31b. *** Reason for rollback *** Breaks //src/test/shell/integration:force_delete_output_test *** Original change description *** Symlink output directories to the correct directory name If the workspace directory is /path/to/my/proj and the name in the WORKSPACE file is "floop", this will symlink the output directories to output_base/execroot/floop instead of output_base/execroot/proj. More prep for #1262, fixes #1681. PiperOrigin-RevId: 156892980
* Automated g4 rollback of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar mstaib2017-05-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causes crash bug in certain circumstances. *** Original change description *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic... PiperOrigin-RevId: 156180015
* Automated g4 rollback of commit e7ab452ac940e645046221dee9b63a670f8a276c.Gravatar mstaib2017-05-16
| | | | | | | | | | | | *** Reason for rollback *** Some of the work supporting this is being rolled back due to uncaught crash bugs. *** Original change description *** Enable dynamic configurations for all builds. PiperOrigin-RevId: 156122472
* Enable dynamic configurations for all builds.Gravatar gregce2017-05-11
| | | | PiperOrigin-RevId: 155673495
* BEP: Provide infrastructure to report configurationsGravatar Klaus Aehlig2017-05-08
| | | | | | | | | | In preparation to support multi-configuration builds, provide infrastructure allowing build events to reference BuildConfigurations. The streaming mechanism will ensure that build configurations are introduced in the stream before being referenced for the first time. Change-Id: I6b96fbebc76a05eff4f75a07e8a9cfbcd57f9c22 PiperOrigin-RevId: 155368666
* Add dynamic config support for top-level configuration hooks.Gravatar gregce2017-05-05
| | | | PiperOrigin-RevId: 155223580
* Implement dynamically configured LIPO builds.Gravatar gregce2017-05-04
| | | | | | | | | | | | | | | Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely. This doesn't actually turn dynamic LIPO on. So the direct effect of this change should be a no-op. The flip will come in a followup change. For now, dynamic LIPO can be triggered with --experimental_dynamic_configs=notrim. PiperOrigin-RevId: 155096056
* BuildOptions cleanup:Gravatar gregce2017-05-04
| | | | | | | | | | | | | | | | | | | | | 1) Remove obsolete originalOptions field. This was originally added to support "parent" transitions, which supported config1 -> config2 -> config1 transitions by having config2 store config1's options. The purpose of this feature was to support LIPO (which has a DATA -> TARGET transition). But https://github.com/bazelbuild/bazel/commit/ff29c0b39cf936a2699b05edd54f483f1a037d93 makes this unnecessary. 2) Support the "disable actions" feature of the LIPO context collector configuration. Putting this in BuildOptions make this dynamic config-compatible. This change intentionally doesn't add disableOptions to BuildOptions.equals() or BuildOptions.hashCode(). It'd be great to do that. But that has semantic consequences. And we've run into really tricky bugs in the past with dynamic configurations and BuildOptions.equals / BuildConfiguration.equals. So it's best to experiment with that in its own change. PiperOrigin-RevId: 154999718
* Automated g4 rollback of commit 7beadb7277453efec7e12b925005e7f0e003b592.Gravatar nharmata2017-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Original CL was rolled backed incorrectly. See post-submit discussion on http://https://github.com/bazelbuild/bazel/commit/7beadb7277453efec7e12b925005e7f0e003b592. *** Original change description *** Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20. *** Reason for rollback *** Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/ Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test Found by bisecting. *** Original change description *** Only allocate some formerly frequently allocated PathFragment objects once. This reduces both gc churn and retained memory usage. RELNOTES: None PiperOrigin-RevId: 154839279
* Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.Gravatar dmarting2017-05-02
| | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/ Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test Found by bisecting. *** Original change description *** Only allocate some formerly frequently allocated PathFragment objects once. This reduces both gc churn and retained memory usage. RELNOTES: None PiperOrigin-RevId: 154821457
* Only allocate some formerly frequently allocated PathFragment objects once.Gravatar nharmata2017-05-02
| | | | | | This reduces both gc churn and retained memory usage. PiperOrigin-RevId: 154718782
* Dynamic configs: build the host config from data, not target options.Gravatar gregce2017-04-26
| | | | | | | This guarantees host tools are always built without LIPO even for LIPO builds. PiperOrigin-RevId: 154210520
* Remove --microcoverage supportGravatar cushon2017-04-24
| | | | | | This feature is unused and depends on emma, which is obsolete. PiperOrigin-RevId: 153713051
* RELNOTES: Fix select condition intersections.Gravatar Googler2017-04-19
| | | | PiperOrigin-RevId: 153531483
* Deprecate use of option category to describe documentation level / usage ↵Gravatar ccalvarin2017-04-19
| | | | | | | | restrictions. Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior. PiperOrigin-RevId: 153525499