| commit | d12c398f96f15f1cfaf9b509c19da1964d422ba6 | [log] [tgz] |
|---|---|---|
| author | Mark Schaller <mschaller@google.com> | Mon Aug 10 19:46:03 2015 +0000 |
| committer | Laszlo Csomor <laszlocsomor@google.com> | Tue Aug 11 07:53:17 2015 +0000 |
| tree | d643ba5322720f0e66e7dcfdde039ce58eaf9de3 | |
| parent | eeaa135b964bb3c715d698b53b8e6fe38adf80a0 [diff] |
Convert invalidated tracking from per-value to per-key The primary user of invalidation tracking is the SkyframeBuildView, which monitored which ConfiguredTargetValues were invalidated. It did that so the SkyframeExecutor could limit its search for artifact conflicts to when the set of configured targets in the build changed. For the newly introduced set of dirtied keys, "dirtiedConfiguredTargetKeys" in SkyframeBuildView, to be as useful as the "dirtyConfiguredTargets" set it replaced, the ConfiguredTargetValueInvalidationReceiver must only remove a key from the set if it was found to be clean when it was re-evaluated. If it was rebuilt, then the key must stay in the set, to represent that the set of configured target values has truly changed. This CL introduces a semantic change that hopefully has a small effect, if any. Previously, the informInvalidationReceiver method in InvalidatingNodeVisitor only informed the invalidationReceiver when a non-null value was invalidated. (This is usually, but not always, equivalent to a non-error value. The uncommon exception is that in keep-going builds, some nodes with errors may also have values, and the invalidator would inform the receiver when such a node was invalidated.) Now, the receiver is informed that a node is invalidated regardless of whether its value is null. Because the receiver uses this information to determine whether artifact conflict search has to be rerun, and that search is expensive, it's possible this change will negatively impact performance. However, the only way an extra search could be invoked is if the invalidated configured target nodes are all in error. That seems like it would happen rarely, if at all. Further cleanup of unused SkyValues returned by markDirty to come in a subsequent CL. -- MOS_MIGRATED_REVID=100304744
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to build the majority of Google‘s software, and thus it has been designed to handle build problems present in Google’s development environment, including:
A massive, shared code repository, in which all software is built from source. Bazel has been built for speed, using both caching and parallelism to achieve this. Bazel is critical to Google's ability to continue to scale its software development practices as the company grows.
An emphasis on automated testing and releases. Bazel has been built for correctness and reproducibility, meaning that a build performed on a continuous build machine or in a release pipeline will generate bitwise-identical outputs to those generated on a developer's machine.
Language and platform diversity. Bazel's architecture is general enough to support many different programming languages within Google, and can be used to build both client and server software targeting multiple architectures from the same underlying codebase.
Find more background about Bazel in our FAQ.