aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/buildtool
Commit message (Collapse)AuthorAge
* Add a <code>getSkylarkOptions</code> helper function to all OptionsProviders.Gravatar juliexxia2018-08-13
| | | | | | This is to allow OptionsProviders to access the new skylark options which aren't held in a fragment class like native options and thus can't be accessed with the traditional <code>get</code> method. Currently this function isn't called anywhere and would just return an empty map. But in the future it will return a map of skylark flag names to values. PiperOrigin-RevId: 208552510
* Fix lock contention in Reporter.startTask/.finishTask by:Gravatar Googler2018-08-13
| | | | | | | | | | | | - Using a thread-safe container to store handlers. - Using a ThreadLocal NumberFormat to produce readable action counts. NumberFormat (or rather the default implementation DecimalFormat) use internal state and locking. - Adding a lock-free fast path for START and FINISH events in ExperimentalEventHandler. RELNOTES: None. PiperOrigin-RevId: 208479896
* Add a flag to evaluate the top level transitions in SkyframeGravatar ulfjack2018-08-02
| | | | | | | | | | | | | | | | | | | | | | | | This adds a new PrepareAnalysisPhaseFunction, which started out as a copy of some existing code from SkyframeExecutor, BuildView, AnalysisPhaseRunner, AnalysisUtils, and ConfigurationResolver, which was then modified to work inside Skyframe. Most of our tests already work with the new code, except for some of the tests related to configuration trimming in combination with dependency cycles. The reason for this is that we can only recover from dependency cycles at the end of a Skyframe invocation, but never inside a Skyframe invocation. The new code therefore cannot return partial results like the old code. This seems to make null builds a bit faster. In my testing, I saw null build times for a single test target go from ~50ms to ~40ms. This is probably due to slightly better caching - it seems that computing the configuration transitions and top-level targets is non-negligible, even if there's only a single top-level configuration for a single top-level target. This might be an even bigger win if there are a lot of top-level targets and configurations. PiperOrigin-RevId: 207083192
* Add option to post ProfileStartedEvent containing the profile's path.Gravatar twerth2018-07-31
| | | | | RELNOTES: None PiperOrigin-RevId: 206741115
* Improve artifact->owner label accounting in two ways. First, don't do the ↵Gravatar janakr2018-07-30
| | | | | | full mapping unless requested. This gets rid of any performance issue for the vast majority of builds. Second, if requested, use a custom data structure so that we don't have to create a full HashSet for artifacts whose only owning labels are their own owner labels. PiperOrigin-RevId: 206610370
* Don't retain memory used by Artifact->owner Label multimap after it's been ↵Gravatar janakr2018-07-26
| | | | | | used at the start of execution. PiperOrigin-RevId: 206230049
* Target pattern eval: use the same number of threads as loadingGravatar ulfjack2018-07-26
| | | | | | | | Instead of using the default thread pool size of 200, use the number set for the loading phase. This is in preparation for interleaving the loading and target pattern eval phases. PiperOrigin-RevId: 206172915
* Remove LoadingResultGravatar ulfjack2018-07-25
| | | | | | | | | | | Instead, refactor the code to use TargetPatternPhaseValue exclusively. This removes the need to convert from TargetPatternPhaseValue to LoadingResult, and prepares for interleaving. It also reduces the number of Skyframe calls which may speed up null builds a bit, as a followup for https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea. PiperOrigin-RevId: 205989338
* Move LoadingPhaseCompleteEvent posting to TargetPatternPhaseFunctionGravatar ulfjack2018-07-24
| | | | | | | | | | | Also simplify LoadingPhaseCompleteEvent, and SkyframeExecutor, and remove LoadingCallback, which is unnecessary now that we only have a single implementation (previously LoadingPhaseRunner). This also removes some of the excessive Skyframe calls introduced by https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea, and prepares for interleaving target pattern eval and loading. PiperOrigin-RevId: 205813197
* Remove gender specific prononuns from Bazel codebaseGravatar hlopko2018-07-23
| | | | | RELNOTES: None. PiperOrigin-RevId: 205635805
* Add aquery as proper command to Bazel.Gravatar twerth2018-07-18
| | | | | RELNOTES: Add aquery command to get analysis time information about the action graph. PiperOrigin-RevId: 205064145
* For all top-level artifacts, track the labels that own them when that is ↵Gravatar janakr2018-07-13
| | | | | | | | available. The owning labels are the labels of the top-level configured targets that requested this artifact to be built (there may be many such targets). In cases where the artifact is added not through a configured target (build-info artifacts and coverage artifacts), the label of the artifact's owner is used. PiperOrigin-RevId: 204432951
* Use generic classes instead of cquery specific class.Gravatar twerth2018-07-10
| | | | | | | Also introduce NamedThreadSafeOutputFormatterCallback for common code. RELNOTES: None PiperOrigin-RevId: 203932877
* Replace instances of Blaze with Bazel.Gravatar Dan Fabulich2018-07-05
| | | | | | | PiperOrigin-RevId: 203300374 Change-Id: Iaa47f870ab2e0cad40a202aad2c7f9430f73c856 PiperOrigin-RevId: 203407392
* Split target pattern eval, config creation, and analysis into a new class.Gravatar twerth2018-06-22
| | | | | | | This is in preparation for interleaving them. RELNOTES: None PiperOrigin-RevId: 201652267
* Add new BuildMetrics event to BEP.Gravatar tomlu2018-06-19
| | | | | | | To start we add just a single metric, the number of actions constructed in the current build. RELNOTES: None PiperOrigin-RevId: 201248490
* Remove support for --discard_actions_after_execution.Gravatar tomlu2018-06-18
| | | | | | | The memory savings from this flag are not worth the complexity, and it interferes with action restarting. RELNOTES: Remove support for --discard_actions_after_execution. PiperOrigin-RevId: 201077905
* Refactoring: uses OutputService for ActionFileSystem injectionGravatar shahan2018-06-18
| | | | | | Moves more Action-oriented from skyframe package, which has become very unwieldy, to action package. This is needed to avoid circular dependencies caused when build-base is needed for skyframe. PiperOrigin-RevId: 200996982
* Add a bit more profiler coverageGravatar ulfjack2018-06-15
| | | | | | | | | | | | | | | | | | The intent is that the main thread has ~zero gaps in the profile (though there may still be small gaps due to the time between one try block and an immediately subsequent try block). We need to be careful not to wrap markPhase calls (or methods that call markPhase) in try blocks for the profiler - the Profiler requires that all markPhase calls happen at top level, and throws an exception if not. This should not have any performance impact - all of these are once per build, or at most once per module per build, and we don't expect a very large number of modules (and if we see an increasing number, we need to change the module API to not have to call every single module, but only those that are actually interested in certain events, maybe with an EventBus-based setup). PiperOrigin-RevId: 200712677
* Add the BuildConfigurationCollection to the AnalysisResultGravatar ulfjack2018-06-15
| | | | | | This is in preparation for interleaving config creation with loading+analysis. PiperOrigin-RevId: 200695071
* Use single source of truth for symlinks and warn when deleting them.Gravatar mstaib2018-06-14
| | | | | | | | | | | | | | | | | | | | | After this change, Bazel prints a warning when --use_top_level_targets_for_symlinks is active and the destination of a symlink would be ambiguous. This also includes a refactoring of OutputDirectoryLinksUtils to use a single source of truth for all symlink operations. This results in a few small visible behavior changes: * Bazel used to delete a convenience symlink with the name of the workspace from the WORKSPACE file... but it didn't create it. * Bazel used to check for a convenience symlink named "includes" when pretty-printing paths... but it didn't create it. * Bazel used to ignore the existence of the "testlogs" symlink when pretty-printing paths... despite that it created it. * Bazel used to prioritize the execroot over the output base when pretty-printing paths... despite that the former contains the latter. RELNOTES: None. PiperOrigin-RevId: 200629863
* Add a convenience method to ProfilerGravatar ulfjack2018-06-14
| | | | | | This reduces our reliance on ProfilerTask. PiperOrigin-RevId: 200538769
* Move BuildView.Options to a new top-level classGravatar ulfjack2018-06-13
| | | | | | | This is in preparation for dismantling BuildView and merging the relevant parts into AnalysisPhaseRunner. PiperOrigin-RevId: 200391088
* Split AnalysisResult into a top-level classGravatar ulfjack2018-06-13
| | | | PiperOrigin-RevId: 200363345
* Add --print_workspace_in_output_paths_if_needed flag.Gravatar mstaib2018-06-12
| | | | | | | | | | | | | | | | When this flag is turned on, and the user's working directory is beneath the workspace (but is not the workspace itself), the workspace's absolute path is printed as a prefix to the convenience symlink. With this flag off, the displayed convenience symlink path is always relative to the user's workspace, even if that isn't the current working directory. (This is the current behavior.) The new (flag-on) behavior will become default soon, and then this flag will be removed. RELNOTES: None. PiperOrigin-RevId: 200278355
* Remove LoadingPhaseRunner, inline the only implementationGravatar ulfjack2018-06-12
| | | | PiperOrigin-RevId: 200210007
* Split TargetPatternEvaluator into two interfacesGravatar ulfjack2018-06-12
| | | | | | | | | | | | | | | | | - the TargetPatternPreloader is still used for query in all its forms - the remaining TargetPatternEvaluator part is no longer used except in tests - also make both implementations stateless and pass the offset to the methods instead; note that they both modify the underlying skyframe graph, so there are side effects to the calls even if there's no direct state anymore The intent is to migrate the relevant tests to LoadingPhaseRunnerTest (which could also now be renamed since it's not doing a loading phase), and then delete the TargetPatternEvaluator interface. This depends on the previous commit that removed the last direct use of TPE from an internal command. PiperOrigin-RevId: 200198067
* Add AutoProfiler-like API to ProfilerGravatar ulfjack2018-06-11
| | | | | | - migrate all startTask/completeTask pairs to the new API PiperOrigin-RevId: 200038703
* Introduce generic post analysis build tool.Gravatar twerth2018-06-11
| | | | | | | This is the first step on the way to a proper action graph query command. RELNOTES: None PiperOrigin-RevId: 200026440
* Remove ActionContextConsumerGravatar ulfjack2018-06-11
| | | | | | | | Instead, add some simple APIs to ExecutorBuilder and inline all the previous subclasses into their corresponding modules. This removes a bunch of boilerplate. PiperOrigin-RevId: 200017162
* Remove the legacy loading phase runnerGravatar ulfjack2018-06-08
| | | | PiperOrigin-RevId: 199775400
* Deletes ActionInputFileCache.Gravatar shahan2018-06-07
| | | | PiperOrigin-RevId: 199732415
* Remove ConfiguredTarget from TargetCompletionValue, since it is no longer ↵Gravatar janakr2018-06-04
| | | | | | needed: we can get the ConfiguredTargetKey directly from the TargetCompletionKey. Since that was the only use of the actual value in EvaluationProgressReceiver#evaluated, remove it, instead just provide a boolean enum that gives whether or not evaluation succeeded. PiperOrigin-RevId: 199178047
* Failing targets are identified by comparing ConfiguredTarget.Key instead of ↵Gravatar cpeyser2018-06-04
| | | | | | ConfiguredTarget. Since ConfiguredTarget does not implement equals(), reference equality has been used until now, and this is not valid for the case where the ConfiguredTarget has been deserialized. PiperOrigin-RevId: 199133926
* Rename BuildEventConverters to BuildEventContextGravatar ulfjack2018-05-17
| | | | | | | This is in preparation for adding options to the class, which can be used to modify the behavior of build events posted to the BEP. PiperOrigin-RevId: 196997573
* Move --track_incremental_state and --keep_state_after_build to ↵Gravatar felly2018-05-15
| | | | | | CommonCommandOptions to better facilitate certain kinds of benchmarking. PiperOrigin-RevId: 196695342
* Add option --experimental_discard_actions_after_execution in order to turn ↵Gravatar janakr2018-05-15
| | | | | | | | it off after a release. Discarding actions hasn't been shown to have a significant positive effect on heap memory usage, after careful research by mschaller@. It's holding back other projects (threading Fileset metadata through) and adding complexity, so it's time to kill it. Out of an abundance of caution, I'll keep actions in memory via a flag flip, then, if it sticks, I'll change the default, and then I'll unwire everything. PiperOrigin-RevId: 196682768
* Delete the FilesetActionContext and its ImplementationGravatar kush2018-05-04
| | | | | RELNOTES: None PiperOrigin-RevId: 195428899
* Kill Legacy Fileset implementation.Gravatar kush2018-05-04
| | | | | RELNOTES: None PiperOrigin-RevId: 195422399
* Do not spawn local actions when available memory is too lowGravatar Josh Pieper2018-05-04
| | | | | | | | | | | | This effectively subsumes all existing memory estimation, as it no longer matters too much how much memory is assigned to each action. WIP: This is a hack, and if it goes in, should almost certainly be hidden behind a configuration option. Closes #4938. PiperOrigin-RevId: 195378568
* Add hook to inform SkyframeExecutor that build is finished.Gravatar janakr2018-04-24
| | | | PiperOrigin-RevId: 194099006
* Add the capability to register a trimming RuleTransitionFactory.Gravatar mstaib2018-04-19
| | | | | | | | | | This RuleTransitionFactory will be applied to all targets after other transitions, and is intended to be used to manually trim the configuration based on tagging of that target. This is a stopgap feature until automatic trimming of configuration can be implemented. RELNOTES: None. PiperOrigin-RevId: 193573013
* Create a new proto output formatter for cquery. Also add flag ↵Gravatar juliexxia2018-04-11
| | | | | | --[no]proto:include_configurations which when used, makes cquery proto output appear exactly like query proto output so tools that are already using this can seamlessly transition. PiperOrigin-RevId: 192470626
* Error out gracefully instead of crashing blaze when --output=transitions is ↵Gravatar juliexxia2018-04-05
| | | | | | used without the --transitions flag PiperOrigin-RevId: 191755762
* Fix build results for aspect builds.Gravatar tomlu2018-04-03
| | | | | | | | | The current output was pretty much completely incorrect. However since the result output was always hidden for the default value of --show_result, users simply didn't see the incorrect output (instead getting no output at all). This CL fixes both the --show_result problem and makes the output correct. RELNOTES: Print correct build result for builds with --aspects flag. PiperOrigin-RevId: 191456352
* Get rid of call to deprecated ConfiguredTarget.getConfiguration()Gravatar juliexxia2018-03-28
| | | | PiperOrigin-RevId: 190777533
* Remove categories from Bazel options.Gravatar ccalvarin2018-03-28
| | | | | | | | | These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format. The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately. RELNOTES: None. PiperOrigin-RevId: 190773778
* Move the default cquery output format to its own callback and standardize ↵Gravatar juliexxia2018-03-27
| | | | | | cquery output callback logic PiperOrigin-RevId: 190667120
* Thread configuration map through TestFilteringCompleteEvent. This isn't the ↵Gravatar janakr2018-03-27
| | | | | | most elegant solution, but I don't have a better idea. PiperOrigin-RevId: 190656869
* Simplified ActionContextConsumer by having it operate on a new class which ↵Gravatar Googler2018-03-26
| | | | | | holds a variety of strategy/context maps. PiperOrigin-RevId: 190491357