GitLab

Bug: 26009364
Change-Id: Ic0001e6fdc62ca2373309bfe3127c5fec64d2d85

Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.

Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502

- 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 c671a7cf)

- 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

I've no idea what these were meant to be for, but they're unused.

Change-Id: I978568bd83f91eb952c35a3a481bd517312062f0

This way we can still access the real compiler as opposed to a wrapped
one.

Change-Id: I17ba30416a3eb8eda056c67faaa8b5957e70caea

This reverts commit a4f84fdf.
Added "export CCACHE_CPP2 := true" to work around ccache bug with clang.
See:
http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html

Change-Id: I2b1fa8fd59c3a113c4028a92a1d16018133c9792

This reverts commit a4f84fdf.
Added "export CCACHE_CPP2 := true" to work around ccache bug with clang.
See:
http://petereisentraut.blogspot.com/2011/09/ccache-and-clang-part-2.html

Change-Id: I2b1fa8fd59c3a113c4028a92a1d16018133c9792

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)

(cherry-picked from AOSP 994c84fb)

Change-Id: Ide800c24f0c2ebbb1cfb358bd8f99ec8a9d41253

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

This reverts commit 0e5ce8be.

Change-Id: I68b776cb915fd7be8299ddb2899907046dddadf3

_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

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

Unfortunately no such flag was found for the host ar on Mac OS X.
https://code.google.com/p/android/issues/detail?id=60705

Change-Id: Ic2f75c871f0b5ae3cf20c1255458f7b921054d67

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>

Change-Id: I4450a8254fe82ed3a670ce653f49381d9c075c8e

Orig-Change-Id: I61137f5bb123dc5f610af9928ed3debdf85ba74d
Signed-off-by: Bruce Beare <bruce.j.beare@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

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

Change-Id: I61137f5bb123dc5f610af9928ed3debdf85ba74d
Signed-off-by: Bruce Beare <brucex.j.beare@intel.com>

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

Fix "argument list too long" build error bug.

Signed-off-by: Erik Gilling <konkers@android.com>

Don't make the simulator default to debug mode.

Remove all global "debug" {C,CPP}FLAGS, which are no longer used.