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
1 file changed
tree: b6cc70648b84afb4fb50850e078630819285fc8e
  1. core/
  2. target/
  3. tests/
  4. tools/
  5. .gitignore
  13. OWNERS
  16. Usage.txt

Android Make Build System

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 writers see

For an outdated reference on files, see build-system.html. Our files look similar, but are entirely different from the 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.