- Don't overwrite [TARGET|HOST]_[CC|CXX] with the [CC|CXX]_WRAPPER prefix,
so that we can disable the wrapper per module.
- Disable ccache on a module when FDO is enabled.
Bug: 22612634
Change-Id: Ibc04a4742d589955066c7eceb43a0da9a2b893bc
(cherry-pick from commit c671a7cf5c)
The previous commit 994c84fb virtually disabled ccache, due to the
deferred evaluation of CC_WRAPPER/CXX_WRAPPER.
Change-Id: Ie0d70a23a55190bd9b24b72edc9158b6976e1d5d
This is to make it possible to wrap the compiler invocations with
custom wrappers (e.g., distcc/goma) by setting the CC_WRAPPER,
CXX_WRAPPER, JAVAC_WRAPPER variables in the build environment (without
having to know in advance the path to the compiler)
Change-Id: Ide800c24f0c2ebbb1cfb358bd8f99ec8a9d41253
_extract-and-include-single-(host|target)-whole-static-lib was written such that
only the first file of a given name would be extracted and included into the new
library. This patch iterates over each identically named archive member,
extracts them individually, and adds them to the new archive.
Bug: 15110069
Change-Id: Ia08c7be6f40bfc8403908a8808898ada479099b1
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
The rules for the 2nd arch are set up in the second inclusion
of shared_library_internal.mk.
Intermediate fils of libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/SHARED_LIBRARIES/libfoo_intermediates/
and the built libfoo.so will be in
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/lib.
Bug: 11654773
Change-Id: I58bbe5a05a65f63bce6279131552f3792000716e
This is the first step to build 32-bit libraries in a 64-bit product.
It will work like this:
1) In the product's BoardConfig.mk, define:
TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT.
The build system uses those variables to set up an additional compiler
environment for the second arch.
2) When parsing Android.mks, the build system sets up rules to build a
module for both the 1st arch and the 2nd arch, unless it's explicitly
asked to skip so.
Android.mk will be adapted if there is additional rule of generating
source files.
The build system will accept arch-specific LOCAL_ variables, such as
LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15,
LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for
various archs at the same time.
3) Install binary of the 2nd arch by adding "<module_name>:32" to
PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32"
will be installed automatically.
Bug: 11654773
Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
Conflicts:
core/combo/TARGET_linux-arm.mk
With these adjustments, cached object files can now be shared across
multiple Android trees on a single workstation:
* Compiler binary modification time no longer causes cache misses,
as a hash of the compiler binary is taken rather than looking
at the mtime and size
* Header file modification time no longer causes cache misses,
the headers are now always hashed
* Macros such as __DATE__ and __TIME__ no longer cause cache misses
* All paths in preprocessed source (due to use of -g) are now relative
These options require ccache 3.1 or later to be used; ccache 2.4 will
ignore these.
Change-Id: I7839637e9dacf7240bd9b7bfaa6406b1db423560
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This patch allows the Window sdk build (lunch sdk-eng; make win_sdk)
to work properly when USE_CCACHE is defined in the environment.
There is no Windows ccache prebuilt, but since we're cross-compiling
from Linux, detect it and use the linux prebuilt binary instead.
Note: Depends on https://review.source.android.com//#change,21755
for a complete solution to the problem.
Change-Id: I0b1b59efae86ee7114225258c9ecf9f257913347
This patch removes support for prelinking from the build system. By now, the
prelinker has outlived its usefulness for several reasons. Firstly, the
speedup that it afforded in the early days of Android is now nullified by the
speed of hardware, as well as by the presence of Zygote. Secondly, the space
savings that come with prelinking (measued at 17MB on a recent honeycomb
stingray build) are no longer important either. Thirdly, prelinking reduces
the effectiveness of Address-Space-Layout Randomization. Finally, since it is
not part of the gcc suite, the prelinker needs to be maintained separately.
The patch deletes apriori, soslim, lsd, isprelinked, and iself from the source
tree. It also removes the prelink map.
LOCAL_PRELINK_MODULE becomes a no-op. Individual Android.mk will get cleaned
separately. Support for prelinking will have to be removed from the recovery
code and from the dynamic loader as well.
Change-Id: I5839c9c25f7772d5183eedfe20ab924f2a7cd411
Merge commit '83f69eb5f905d47581bed141b7f5103362390339' into gingerbread-plus-aosp
* commit '83f69eb5f905d47581bed141b7f5103362390339':
Prepend ccache to CC/CXX if necessary.
In case TARGET_CC is assigned with HOST_CC (eg, simulator build),
ccache will be prepended twice before this CL.
Bug: 3069576
Change-Id: I2ee44faea3a2795cf389ad6f80e4066a02b43be9
The only OS-ARCH combo that would have benefited from it
is linux-x86, but it explicitly used separate configurations
for the HOST_ and TARGET_ side of things.
This makes is clear which files are related to the HOST_
configuration and which ones are related to the TARGET_
configuration, and expands $(combo_target) to the only
possible/reasonable value that it could have had in every
file.
This also cleans up the simulator, by moving it in a single
place in TARGET_linux_x86 (since the only part that's special
is to use HOST_ settings even when building TARGET_ modules).
Change-Id: I2420eeb8cfe539f5807ec99cb3177ffb9f2476d5
