aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/config
Commit message (Collapse)AuthorAge
* Clean up ExecutionRequirementsGravatar ulfjack2017-11-29
| | | | | | | | | | | | | | | | | | | - remove BaseSpawn.Local; instead, all callers pass in the full set of execution requirements they want to set - disable caching and sandboxing for the symlink tree action - it does not declare outputs, so it can't be cached or sandboxed (fixes #4041) - centralize the existing execution requirements in the ExecutionRequirements class - centralize checking for execution requirements in the Spawn class (it's possible that we may need a more decentralized, extensible design in the future, but for now having them in a single place is simple and effective) - update the documentation - forward the relevant tags to execution requirements in TargetUtils (progress on #3960) - this also contributes to #4153 PiperOrigin-RevId: 177288598
* Make check_fileset_dependencies_recursively flag a no-op. We will always ↵Gravatar kush2017-11-28
| | | | | | | behave as if this flag is true. RELNOTES: None PiperOrigin-RevId: 177219652
* Remove outdated javadoc parameter.Gravatar gregce2017-11-16
| | | | PiperOrigin-RevId: 176006176
* toolchain_type can export make variables from the toolchain instead of theGravatar cpeyser2017-11-13
| | | | | | configuration. PiperOrigin-RevId: 175532550
* RELNOTES: --keep_incrementality_data flag allows Bazel servers to be run in ↵Gravatar janakr2017-11-12
| | | | | | | | | | | | | | memory-saving non-incremental mode independent of --batch and --discard_analysis_cache. A command run with --nokeep_incrementality_data will discard data that would be needed for incremental builds. Subsequent commands can be sent to the same server, but they will not get the benefit of incrementality from this command. However, if --keep_incrementality_data is specified on a subsequent command, the commands after that will get the benefits of incrementality. There are two benefits to not being dependent on --batch. First, this allows Bazel servers to be run in extreme memory-saving mode without the startup penalties (JVM startup, JITting) that --batch execution imposes. Second, this allows Bazel developers to inspect the state of a Bazel server after an extreme memory-saving build. In order to avoid discarding data unnecessarily (for instance, on a "bazel info used-heap-size-after-gc" or "bazel dump --skyframe=summary") the actual resetting of the graph is done lazily, right before its use in SequencedSkyframeExecutor#sync. This is morally a partial rollback of https://github.com/bazelbuild/bazel/commit/98cd82cbdcac7c48164a611c5a9aa8fc2f1720ef. For now, our tests specify all of the flags. After this change sticks, I plan to get rid of the --batch flag from these tests, which should allow for some clean-ups. Eventually --batch and --discard_analysis_cache may not imply that we don't keep incremental state: we can require that it be specified explicitly. PiperOrigin-RevId: 175335075
* 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
* Finish making --auto_cpu_environment_group non-experimental.Gravatar jcater2017-11-09
| | | | PiperOrigin-RevId: 175027144
* Avoid crash when a test and its alias are specified on the command line for ↵Gravatar lberki2017-11-03
| | | | | | | "blaze test". RELNOTES: None. PiperOrigin-RevId: 174386473
* Move TransitiveTargetKey to a dedicated top-level classGravatar ulfjack2017-10-30
| | | | PiperOrigin-RevId: 173873310
* Add a deprecation warning to the check_fileset_dependencies_resursively flag.Gravatar kush2017-10-26
| | | | | RELNOTES: none PiperOrigin-RevId: 173432000
* Add Path argument to supportsModifications, supports*LinksNatively.Gravatar tomlu2017-10-20
| | | | | | | | This works better with UnionFileSystem, as (eg.) different mapped file systems might not agree on whether they are read-only. No actual code changes have been made that actually uses this argument, so this should be a behaviour no-op. PiperOrigin-RevId: 172782759
* Set the platform name in the build event stream to the CPU instead of the ↵Gravatar lberki2017-10-20
| | | | | | | | | toolchain identifier. This is necessary because we don't want BuildConfiguration to depend on BUILD and CROSSTOOL files anymore and this is possible because the toolchain ID was conceived as a unique identifier for the configuration in the build event stream, which it isn't anyway, and this way it's at least more human-readable. RELNOTES: None. PiperOrigin-RevId: 172725386
* Loop in top-level transition logic to configurable query to give more ↵Gravatar juliexxia2017-10-20
| | | | | | accurate results. Some refactoring done to get custom query code out of BuildView and into resolvers. PiperOrigin-RevId: 172647838
* Start process of making auto_cpu_environment_group non-experimental.Gravatar jcater2017-10-18
| | | | | | | | Adds a legacy flag so clients can continue to use both experimental_auto_cpu_environment_group and auto_cpu_environment_group until uses can be cleaned up. PiperOrigin-RevId: 172470616
* Deprecate methods in ConfigurationEnvironment that give access to ↵Gravatar lberki2017-10-16
| | | | | | | ConfigurationFragmentFactory instances to contents of BUILD files and to the file system. RELNOTES: None. PiperOrigin-RevId: 172086610
* SplitTransitionProvider no longer requires the attributes it uses are "Non ↵Gravatar cparsons2017-10-11
| | | | | | | Configurable" RELNOTES: None. PiperOrigin-RevId: 171751391
* Move --experimental_allow_runtime_deps_on_neverlink to JavaOptions.Gravatar mstaib2017-10-06
| | | | | | | This migration flag only affects Java rules. RELNOTES: None. PiperOrigin-RevId: 171026607
* Categorize build options for BuildConfiguration.Gravatar gregce2017-10-06
| | | | PiperOrigin-RevId: 171017483
* Move --plugin to JavaOptions and remove --plugin_copt.Gravatar mstaib2017-09-26
| | | | | | | | | | | | | | | --plugin, though once used for C++, is currently a Java-specific flag. --plugin_copt is currently a total no-op, and has been for a long time. Moving these to the Java fragment is a little neater and helps get one step closer to enforcing LateBoundDefault fragment access. Additionally, since the "no plugins with duplicate names" restriction was added to work with plugin_copt, this restriction can be lifted. It no longer adds any value. RELNOTES: None. PiperOrigin-RevId: 169981221
* Stop injecting embedded artifacts. They're never used by anyone in Skyframe, ↵Gravatar janakr2017-09-26
| | | | | | and error-checking for their existence is already done by the client. PiperOrigin-RevId: 169966701
* Move --build_python_zip into PythonConfiguration.Gravatar mstaib2017-09-21
| | | | | | | | There's no need for it in the core configuration options, as it's used exclusively by Python rules. RELNOTES: None. PiperOrigin-RevId: 169435643
* Move ConfiguredTargetFunction dynamic config selection to its own class.Gravatar gregce2017-09-20
| | | | | | | | Also clarify the interfaces *TransitionResolver* - which determines what transition to apply to an input configuration and *ConfigurationResolver* - which determines the output configuration from that transition. PiperOrigin-RevId: 169311986
* LateBoundDefault: enforce access to a single fragment (or none).Gravatar mstaib2017-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no way to enforce that LateBoundDefaults only access the fragments that they declare. This means that LateBoundDefaults can fail to declare fragments at all, or declare the wrong ones, and still have no troubles. But when trimming, these fragments must be declared, because otherwise they will not necessarily be available. This change refactors LateBoundDefault to declare a single fragment type, not a set. All existing LateBoundDefaults use sets with a single element or no elements at all for their set of fragment classes, so this does not limit anything being done currently. To account for LateBoundDefaults which do not use configuration at all, typically those which only want to access the configured attribute map, it is possible for Void to be the fragment class which is requested. To account for LateBoundDefaults which need to access methods of the BuildConfiguration instance itself, it is possible for BuildConfiguration to be the fragment class which is requested; however, this is unsafe, so it is only a temporary state until a way to do this without also giving access to all of the fragments can be added. Drive-by refactoring: LateBoundDefaults' values are now typed. All actual production LateBoundDefaults were Label or List<Label> typed, through the LateBoundLabel and LateBoundLabelList subclasses. These subclasses have been removed, and LateBoundDefault has two type parameters, one for the type of its input, and one for the type of its output. RELNOTES: None. PiperOrigin-RevId: 169242278
* Lots more cleanup of "dynamic configurations" comments and test code.Gravatar gregce2017-09-14
| | | | PiperOrigin-RevId: 168607439
* Static config removal TODO cleanup.Gravatar gregce2017-09-14
| | | | PiperOrigin-RevId: 168583577
* Remove outdated Attribute.Configurator interface.Gravatar gregce2017-09-13
| | | | | | | | With dynamic configurations we no longer need a special class to apply transitions: a simple patch transition bound to an attribute works just as well. PiperOrigin-RevId: 168442602
* Remove unused class after removal of BazelConfigurationCollection.Gravatar gregce2017-09-13
| | | | | | Also pipe keepGoing back into initial configuration creation. PiperOrigin-RevId: 168412512
* Remove outdated defaultsToSelf.Gravatar gregce2017-09-12
| | | | | | Part of the static config cleanup effort. PiperOrigin-RevId: 168270713
* Remove the unused fallback argument from getHost() and the unused method ↵Gravatar lberki2017-09-12
| | | | | | | getPotentialSplitTransitions() from FragmentOptions. RELNOTES: None. PiperOrigin-RevId: 168218102
* Move caching of OptionDefinitions to be static, and remove uncached ↵Gravatar ccalvarin2017-09-01
| | | | | | | | | | extractions of OptionDefinitions. We already had caching of OptionsData objects, for a list of OptionsBases, but repeated the reflective work for the same OptionsBase if it appeared in different lists. Now that the @Option-annotation specific state is isolated to the OptionDefinition object, this can be trivially cached by OptionsBase. There are a few additional convenient side effects to this change. This should slightly decrease the memory use of the OptionsParser, since it already cached this map per options-base, and now only requires a single copy. It also means that parts of the code base that needed details of an option's definition no longer need to either obtain an option definition themselves or need access to an OptionsData object, which should be private to the OptionsParser anyway. PiperOrigin-RevId: 167158902
* 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
* Move default value & converter finding logic to the OptionDefinition class.Gravatar ccalvarin2017-08-30
| | | | | | | | | | | Removes some duplicate computation by memoizing the results. Consolidates caching into a single optionDefinition object, instead of having multiple caches that go from the option name to different parts of what defines an option. Fly-by cleanup of OptionDescription's contents, all contents that are statically defined as part of an option are in OptionDefintion, while expansion data, which depends on the existence of other options, is more clearly stored separately. Will move the converter-to-option type matching sanity checks to a compile time check in a later change. RELNOTES: None. PiperOrigin-RevId: 166912716
* Add OptionDefinition layer between the @Option annotation and its fields and ↵Gravatar ccalvarin2017-08-22
| | | | | | | | | | | the options parser. Removes any direct reads of the annotation outside of OptionDefinition. This allows for fewer manual checks for the annotation's existence, unifies error wording, and paves the way for potentially generifying the OptionsParser to accept different @Option-equivalent annotations. Also allows for cleanup of duplicate code by giving @Option-specific operations a clear home, such as sorts and default logic. In followup changes, we can eliminate some unnecessarily complex caching by instead memoizing values in the OptionDefinition. This will have the positive side effect of making sure reads come from the cached values. RELNOTES: None. PiperOrigin-RevId: 166019075
* Add a --build_runfile_manifests flag which controls production ofGravatar Googler2017-08-22
| | | | | | | | foo_test.runfiles_manifest files. These are the largest local outputs in many builds, and unnecessary for remote test execution. RELNOTES: New --build_runfile_manifests flag controls production of runfiles manifests. PiperOrigin-RevId: 166001477
* Replace TransitionApplier interface with a dedicated class.Gravatar gregce2017-08-21
| | | | | | | | | | | | | | | This accomplishes a few goals: 1. Removes the outdated BuildConfiguration.StaticConfigurationApplier code. 2. Removes the TransitionApplier abstraction completely. This was an awkward bridge meant to support both static and dynamic implementations. 3. Moves transition logic to its own dedicated class: ConfigurationResolver. This no longer belongs in BuildConfiguration, which we ultimately want to become a simple <key, value> map. Part of the static config cleanup effort. PiperOrigin-RevId: 165736955
* Remove BuildConfiguration.useDynamicConfigurations.Gravatar gregce2017-08-18
| | | | | | | | This is always true. Part of the static config cleanup effort. PiperOrigin-RevId: 165628823
* Remove ConfigurationCollection{Function,Value}, ↵Gravatar gregce2017-08-18
| | | | | | | | BuildConfigurationCollection.Transitions. Part of the static config cleanup effort. PiperOrigin-RevId: 165607492
* Expose android configuration to skylark (android_sdk and apk_signing_method)Gravatar Googler2017-08-18
| | | | PiperOrigin-RevId: 165596223
* Remove RuleClass.Configurator and obsolete LIPO_ON_DEMAND uses.Gravatar gregce2017-08-18
| | | | | | | | Dynamic configs use RuleTransitionFactory instead. Part of the static config cleanup effort. PiperOrigin-RevId: 165590679
* Honor --nobuild_runfile_links for non-tests, and propagate it to theGravatar Googler2017-08-17
| | | | | | | | | | | | | host configuration. I think the comment I'm deleting is misleading. PAR file construction already has special handling of the input manifest, and host tools do get their runfiles when executed remotely. They don't get them for local execution, but users who care about that don't need to pass the non-default --nobuild_runfile_links option. RELNOTES: None. PiperOrigin-RevId: 165535870
* Remove ConfigurationFactory as part of the static configuration cleanup.Gravatar gregce2017-08-17
| | | | PiperOrigin-RevId: 165478994
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 11:03:16 +0000