p96705831
/
platform_build
forked from openkylin/platform_build
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
platform_build/core/combo/select.mk

109 lines
3.9 KiB
Makefile
Raw Normal View History

Get rid of $(combo_target) 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
2010-02-24 04:36:56 +08:00
#
# Copyright (C) 2006 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.
#
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# Select a combo based on the compiler being used.
#
# Inputs:
# combo_target -- prefix for final variables (HOST_ or TARGET_)
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
# combo_2nd_arch_prefix -- it's defined if this is loaded for TARGET_2ND_ARCH.
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
#
# Build a target string like "linux-arm" or "darwin-x86".
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
ifdef combo_2nd_arch_prefix
combo_os_arch := $($(combo_target)OS)-$(TARGET_2ND_ARCH)
else
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
combo_os_arch := $($(combo_target)OS)-$($(combo_target)ARCH)
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
endif
combo_var_prefix := $(combo_2nd_arch_prefix)$(combo_target)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Get rid of $(combo_target) 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
2010-02-24 04:36:56 +08:00
# Set reasonable defaults for the various variables
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
$(combo_var_prefix)CC := $(CC)
$(combo_var_prefix)CXX := $(CXX)
$(combo_var_prefix)AR := $(AR)
$(combo_var_prefix)STRIP := $(STRIP)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
$(combo_var_prefix)BINDER_MINI := 0
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
$(combo_var_prefix)HAVE_EXCEPTIONS := 0
$(combo_var_prefix)HAVE_UNIX_FILE_PATH := 1
$(combo_var_prefix)HAVE_WINDOWS_FILE_PATH := 0
$(combo_var_prefix)HAVE_RTTI := 1
$(combo_var_prefix)HAVE_CALL_STACKS := 1
$(combo_var_prefix)HAVE_64BIT_IO := 1
$(combo_var_prefix)HAVE_CLOCK_TIMERS := 1
$(combo_var_prefix)HAVE_PTHREAD_RWLOCK := 1
$(combo_var_prefix)HAVE_STRNLEN := 1
$(combo_var_prefix)HAVE_STRERROR_R_STRRET := 1
$(combo_var_prefix)HAVE_STRLCPY := 0
$(combo_var_prefix)HAVE_STRLCAT := 0
$(combo_var_prefix)HAVE_KERNEL_MODULES := 0
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
$(combo_var_prefix)GLOBAL_CFLAGS := -fno-exceptions -Wno-multichar
$(combo_var_prefix)RELEASE_CFLAGS := -O2 -g -fno-strict-aliasing
$(combo_var_prefix)GLOBAL_CPPFLAGS :=
$(combo_var_prefix)GLOBAL_LDFLAGS :=
$(combo_var_prefix)GLOBAL_ARFLAGS := crsPD
Set up rules to build shared libraries for TARGET_2ND_ARCH 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
2014-01-17 04:36:34 +08:00
$(combo_var_prefix)GLOBAL_LD_DIRS :=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
$(combo_var_prefix)EXECUTABLE_SUFFIX :=
$(combo_var_prefix)SHLIB_SUFFIX := .so
$(combo_var_prefix)JNILIB_SUFFIX := $($(combo_var_prefix)SHLIB_SUFFIX)
$(combo_var_prefix)STATIC_LIB_SUFFIX := .a
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# Now include the combo for this specific target.
Get rid of $(combo_target) 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
2010-02-24 04:36:56 +08:00
include $(BUILD_COMBOS)/$(combo_target)$(combo_os_arch).mk
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
ifneq ($(USE_CCACHE),)
select.mk: Tune ccache options 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>
2012-08-14 04:45:50 +08:00
# The default check uses size and modification time, causing false misses
# since the mtime depends when the repo was checked out
export CCACHE_COMPILERCHECK := content
# 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
export CCACHE_SLOPPINESS := time_macros,include_file_mtime,file_macro
# 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.
export CCACHE_BASEDIR := /
Allow win_sdk build with USE_CCACHE=1 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
2011-03-12 20:19:01 +08:00
CCACHE_HOST_TAG := $(HOST_PREBUILT_TAG)
# If we are cross-compiling Windows binaries on Linux
# then use the linux ccache binary instead.
ifeq ($(HOST_OS)-$(BUILD_OS),windows-linux)
CCACHE_HOST_TAG := linux-$(BUILD_ARCH)
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
2010-10-08 01:45:02 +08:00
endif
Reference the new prebuilt ccache location. Change-Id: I4450a8254fe82ed3a670ce653f49381d9c075c8e
2012-01-10 03:52:23 +08:00
ccache := prebuilts/misc/$(CCACHE_HOST_TAG)/ccache/ccache
Allow win_sdk build with USE_CCACHE=1 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
2011-03-12 20:19:01 +08:00
# Check that the executable is here.
ccache := $(strip $(wildcard $(ccache)))
ifdef ccache
# prepend ccache if necessary
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
ifneq ($(ccache),$(firstword $($(combo_var_prefix)CC)))
$(combo_var_prefix)CC := $(ccache) $($(combo_var_prefix)CC)
Allow win_sdk build with USE_CCACHE=1 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
2011-03-12 20:19:01 +08:00
endif
Load compiler environment for a second arch. 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
2013-12-28 03:09:36 +08:00
ifneq ($(ccache),$(firstword $($(combo_var_prefix)CXX)))
$(combo_var_prefix)CXX := $(ccache) $($(combo_var_prefix)CXX)
Allow win_sdk build with USE_CCACHE=1 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
2011-03-12 20:19:01 +08:00
endif
ccache =
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
2010-10-08 01:45:02 +08:00
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif