| commit | 7556703f0dfab14c91c03dab1a3c25f6386268d4 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Thu Apr 05 15:25:59 2018 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Thu Apr 05 15:25:59 2018 -0700 |
| tree | b6cc70648b84afb4fb50850e078630819285fc8e | |
| parent | a975fe9c24550603c6d8bf82ca5c4a71d655ea95 [diff] |
Remove our binary of ccache Our binary was rather old, and for a variety of reasons we haven't kept it updated. We've been running into a handful of reliability issues that would have been fixed with an update, and a few reproducibility / correctness issues that may or may not be fixed with newer versions. For local no-change full rebuilds, ccache can still save ~35% of the build time (but adds a few minutes to initially populate the cache). But most local uses should be using incremental builds anyways, not clean rebuilds. Or you're doing builds of different configurations, which wouldn't be cache hits either, and would make your cache even larger. At a large scale, we haven't seen a significant performance difference between having ccache on or off. This may be different if you've got very good build locality, or a very large cache -- but if you've got good build locality, it's reasonable to do incremental builds (not for release builds, and while running `m installclean` in between builds). So for our cases, we'd prefer the stability and correctness of not using ccache, but if you still want to use ccache, continue setting USE_CCACHE and also set CCACHE_EXEC to the path of your ccache executable. Bug: 32748498 Bug: 72408185 Test: performance testing of USE_CCACHE=false vs true locally Test: turned off ccache for a collection of targets Test: CCACHE_EXEC=/usr/bin/ccache USE_CCACHE=true m Change-Id: I7117fe3107bd98521051ae343038a38f7e855502
This is the Makefile-based portion of the Android Build System.
For documentation on how to run a build, see Usage.txt
For a list of behavioral changes useful for Android.mk writers see Changes.md
For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.
This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.