2015-07-21 09:40:18 +08:00
|
|
|
#
|
|
|
|
# Copyright (C) 2015 The Android Open Source Project
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
#
|
|
|
|
|
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
2018-04-06 06:25:59 +08:00
|
|
|
# We no longer provide a ccache prebuilt.
|
|
|
|
#
|
|
|
|
# Ours was old, and had a number of issues that triggered non-reproducible
|
|
|
|
# results and other failures. Newer ccache versions may fix some of those
|
|
|
|
# issues, but at the large scale of our build servers, we weren't seeing
|
|
|
|
# significant performance gains from using ccache -- you end up needing very
|
|
|
|
# good locality and/or very large caches if you're building many different
|
|
|
|
# configurations.
|
|
|
|
#
|
|
|
|
# Local no-change full rebuilds were showing better results, but why not just
|
|
|
|
# use incremental builds at that point?
|
|
|
|
#
|
|
|
|
# So if you still want to use ccache, continue setting USE_CCACHE, but also set
|
|
|
|
# the CCACHE_EXEC environment variable to the path to your ccache executable.
|
|
|
|
ifneq ($(CCACHE_EXEC),)
|
2015-12-18 14:26:17 +08:00
|
|
|
ifneq ($(filter-out false,$(USE_CCACHE)),)
|
2015-07-21 09:40:18 +08:00
|
|
|
# The default check uses size and modification time, causing false misses
|
|
|
|
# since the mtime depends when the repo was checked out
|
2018-02-27 18:15:32 +08:00
|
|
|
CCACHE_COMPILERCHECK ?= content
|
2015-07-21 09:40:18 +08:00
|
|
|
|
|
|
|
# See man page, optimizations to get more cache hits
|
|
|
|
# implies that __DATE__ and __TIME__ are not critical for functionality.
|
|
|
|
# Ignore include file modification time since it will depend on when
|
|
|
|
# the repo was checked out
|
2018-02-27 18:15:32 +08:00
|
|
|
CCACHE_SLOPPINESS := time_macros,include_file_mtime,file_macro
|
2015-07-21 09:40:18 +08:00
|
|
|
|
|
|
|
# Turn all preprocessor absolute paths into relative paths.
|
|
|
|
# Fixes absolute paths in preprocessed source due to use of -g.
|
|
|
|
# We don't really use system headers much so the rootdir is
|
|
|
|
# fine; ensures these paths are relative for all Android trees
|
|
|
|
# on a workstation.
|
2018-02-27 18:15:32 +08:00
|
|
|
CCACHE_BASEDIR := /
|
2015-07-21 09:40:18 +08:00
|
|
|
|
|
|
|
# Workaround for ccache with clang.
|
|
|
|
# See http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html
|
2018-02-27 18:15:32 +08:00
|
|
|
CCACHE_CPP2 := true
|
2015-07-21 09:40:18 +08:00
|
|
|
|
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
2018-04-06 06:25:59 +08:00
|
|
|
ifndef CC_WRAPPER
|
|
|
|
CC_WRAPPER := $(CCACHE_EXEC)
|
2015-07-21 09:40:18 +08:00
|
|
|
endif
|
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
2018-04-06 06:25:59 +08:00
|
|
|
ifndef CXX_WRAPPER
|
|
|
|
CXX_WRAPPER := $(CCACHE_EXEC)
|
|
|
|
endif
|
|
|
|
endif
|
2015-07-21 09:40:18 +08:00
|
|
|
endif
|