openkylin
/
platform_build
mirror of https://gitee.com/openkylin/platform_build.git
9
0
Fork 1
Code Issues Projects Releases Wiki Activity
platform_build/core/envsetup.mk

606 lines
24 KiB
Makefile
Raw Normal View History

auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# Variables we check:
# HOST_BUILD_TYPE = { release debug }
# TARGET_BUILD_TYPE = { release debug }
# and we output a bunch of variables, see the case statement at
# the bottom for the full list
# OUT_DIR is also set to "out" if it's not already set.
# this allows you to set it to somewhere else if you like
Add new variable SCAN_EXCLUDE_DIRS; specifies directories to exclude when searching source tree. These directories are excluded in addition to OUT_DIR. This can be useful if your build system has other output directories beyond what OUT_DIR is set to. Change-Id: I6d98a85bcc8c89279e939406a7fec32547e8922f
2015-06-10 01:35:45 +08:00
# SCAN_EXCLUDE_DIRS is an optional, whitespace separated list of
# directories that will also be excluded from full checkout tree
# searches for source or make files, in addition to OUT_DIR.
# This can be useful if you set OUT_DIR to be a different directory
# than other outputs of your build system.
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add min and max supported versions Add MIN_PLATFORM_VERSION and MAX_PLATFORM_VERSION to track the range of releases that are expected to be released from the current branch. Also simplify version_defaults.mk by moving most of the code to envsetup.mk. Test: build/make/tests/envsetup_tests.sh Change-Id: I4f19c31c267e202f8f5ba1384a8b4385d725f9d7
2017-03-29 04:07:56 +08:00
# Returns all words in $1 up to and including $2
define find_and_earlier
$(strip $(if $(1),
$(firstword $(1))
$(if $(filter $(firstword $(1)),$(2)),,
$(call find_and_earlier,$(wordlist 2,$(words $(1)),$(1)),$(2)))))
endef
#$(warning $(call find_and_earlier,A B C,A))
#$(warning $(call find_and_earlier,A B C,B))
#$(warning $(call find_and_earlier,A B C,C))
#$(warning $(call find_and_earlier,A B C,D))
define version-list
$(1)PR1 $(1)PD1 $(1)PD2 $(1)PM1 $(1)PM2
endef
ALL_VERSIONS := O P Q R S T U V W X Y Z
ALL_VERSIONS := $(foreach v,$(ALL_VERSIONS),$(call version-list,$(v)))
# Filters ALL_VERSIONS down to the range [$1, $2], and errors if $1 > $2 or $3 is
# not in [$1, $2]
# $(1): min platform version
# $(2): max platform version
# $(3): default platform version
define allowed-platform-versions
$(strip \
$(if $(filter $(ALL_VERSIONS),$(1)),,
$(error Invalid MIN_PLATFORM_VERSION '$(1)'))
$(if $(filter $(ALL_VERSIONS),$(2)),,
$(error Invalid MAX_PLATFORM_VERSION '$(2)'))
$(if $(filter $(ALL_VERSIONS),$(3)),,
$(error Invalid DEFAULT_PLATFORM_VERSION '$(3)'))
$(eval allowed_versions_ := $(call find_and_earlier,$(ALL_VERSIONS),$(2)))
$(if $(filter $(allowed_versions_),$(1)),,
$(error MIN_PLATFORM_VERSION '$(1)' must be before MAX_PLATFORM_VERSION '$(2)'))
$(eval allowed_versions_ := $(1) \
$(filter-out $(call find_and_earlier,$(allowed_versions_),$(1)),$(allowed_versions_)))
$(if $(filter $(allowed_versions_),$(3)),,
$(error DEFAULT_PLATFORM_VERSION '$(3)' must be between MIN_PLATFORM_VERSION '$(1)' and MAX_PLATFORM_VERSION '$(2)'))
$(allowed_versions_))
endef
#$(warning $(call allowed-platform-versions,OPR1,PPR1,OPR1))
#$(warning $(call allowed-platform-versions,OPM1,PPR1,OPR1))
Print the platform version and version codename in the big build header.
2009-05-13 12:45:23 +08:00
# Set up version information.
include $(BUILD_SYSTEM)/version_defaults.mk
Add min and max supported versions Add MIN_PLATFORM_VERSION and MAX_PLATFORM_VERSION to track the range of releases that are expected to be released from the current branch. Also simplify version_defaults.mk by moving most of the code to envsetup.mk. Test: build/make/tests/envsetup_tests.sh Change-Id: I4f19c31c267e202f8f5ba1384a8b4385d725f9d7
2017-03-29 04:07:56 +08:00
ENABLED_VERSIONS := $(call find_and_earlier,$(ALL_VERSIONS),$(TARGET_PLATFORM_VERSION))
$(foreach v,$(ENABLED_VERSIONS), \
$(eval IS_AT_LEAST_$(v) := true))
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# ---------------------------------------------------------------
# If you update the build system such that the environment setup
# or buildspec.mk need to be updated, increment this number, and
# people who haven't re-run those will have to do so before they
# can build. Make sure to also update the corresponding value in
# buildspec.mk.default and envsetup.sh.
Add TARGET_PLATFORM_VERSION to lunch lunch can now take combos in the form: $TARGET_PRODUCT $TARGET_PRODUCT-$TARGET_BUILD_VARIANT $TARGET_PRODUCT-$TARGET_BUILD_VARIANT-$TARGET_PLATFORM_VERSION If all 3 are not specified the unspecified ones will take the default values provided by the build system (eng, and currently OPR1). In addition, error handling for invalid products, variants and versions is moved to the build system. Bug: 34972208 Test: build/make/tests/envsetup_tests.sh Change-Id: Ib0aaa98633448ba9bd8df911704c9cb3a8ebbe85
2017-03-22 08:41:03 +08:00
CORRECT_BUILD_ENV_SEQUENCE_NUMBER := 13
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Rewrite link type checking All the new features are turned off for now, since multiple branches and products need to be verified before they can be turned on. So everything should behave the same as today, except for no partition-based warnings. Instead of the current link type checks that happen during the build, run as many as possible immediately after loading all the Android.mk files. If we're allowing missing dependencies ('mm', ALLOW_MISSING_DEPENDENCIES, tapas, etc), we'll defer the link type checks to during the build. If we're not allowing missing dependencies, we'll produce a better error message to the user about the missing dependencies. See core/main.mk for a description of the storage format. This also remove the partition-based type checking. It hasn't worked all that well, particularly with ASAN builds. The new VNDK checks will handle the most pressing cases. Test: Verify all link_type files and dependencies are the same: grep link_type: out/build-aosp_arm64.ninja | sed -E "s/ rule[0-9]+//" | sort Change-Id: Id643658b9d9e84f99f5db0d526aad88c1f5d3417
2017-04-08 15:31:31 +08:00
# ---------------------------------------------------------------
# Whether we can expect a full build graph
ALLOW_MISSING_DEPENDENCIES := $(filter true,$(ALLOW_MISSING_DEPENDENCIES))
ifneq ($(TARGET_BUILD_APPS),)
ALLOW_MISSING_DEPENDENCIES := true
endif
ifneq ($(filter true,$(SOONG_ALLOW_MISSING_DEPENDENCIES)),)
ALLOW_MISSING_DEPENDENCIES := true
endif
ifneq ($(ONE_SHOT_MAKEFILE),)
ALLOW_MISSING_DEPENDENCIES := true
endif
.KATI_READONLY := ALLOW_MISSING_DEPENDENCIES
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# ---------------------------------------------------------------
Remove the simulator target from all makefiles. Bug: 5010576 Change-Id: Ie814f4c8d3aa1e7cc7f5735822ab25542f36cf62
2011-07-12 13:11:46 +08:00
# The product defaults to generic on hardware
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# NOTE: This will be overridden in product_config.mk if make
# was invoked with a PRODUCT-xxx-yyy goal.
ifeq ($(TARGET_PRODUCT),)
Remove the unnecessary full_x86_64 and full_mips64. For historical reason, the aosp_* products were named full_*. We keep the full, full_x86 and full_mips in case some tools still reference these legacy names; But no reason the have the full_* product names for the new 64-bit archs. Change-Id: I240ed0c6ded0ded2d80603bd0c5ff24750999afc
2015-06-09 02:57:26 +08:00
TARGET_PRODUCT := aosp_arm
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
# the variant -- the set of files that are included for a build
ifeq ($(strip $(TARGET_BUILD_VARIANT)),)
TARGET_BUILD_VARIANT := eng
endif
# ---------------------------------------------------------------
# Set up configuration for host machine. We don't do cross-
MIPS support to *.mk files and envsetup.sh Change-Id: Iba4d046e3202524b29cfe32980927f8cc0aa8496 Signed-off-by: Chris Dearman <chris@mips.com> Signed-off-by: Raghu Gandham <raghu@mips.com>
2012-07-26 10:57:22 +08:00
# compiles except for arm/mips, so the HOST is whatever we are
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# running on
UNAME := $(shell uname -sm)
# HOST_OS
ifneq (,$(findstring Linux,$(UNAME)))
Support host multilib build 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
2014-04-18 01:03:35 +08:00
HOST_OS := linux
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
ifneq (,$(findstring Darwin,$(UNAME)))
Support host multilib build 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
2014-04-18 01:03:35 +08:00
HOST_OS := darwin
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
ifneq (,$(findstring Macintosh,$(UNAME)))
Support host multilib build 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
2014-04-18 01:03:35 +08:00
HOST_OS := darwin
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
Speed up lunch/tapas/etc. shell utility functions. 1. Combined ~10 calls to the make build system to only one. We added a phony target "dump-many-vars" to the build system to dump "<var>=<value>" pairs. We then store the pairs as shell variables. With this cache get_build_var/get_abs_build_var can just return the shell variables instead of querying the build system. 2. Prune .git when we search for AndroidProduct.mks. In internal source tree lunch time was reduced from ~15s to ~1.5s. Bug: 27429759 Change-Id: I24e88598f6fab598ef26518885fd5e86e71a772d
2016-03-04 12:57:21 +08:00
HOST_OS_EXTRA:=$(shell python -c "import platform; print(platform.platform())")
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
# BUILD_OS is the real host doing the build.
BUILD_OS := $(HOST_OS)
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OS :=
# We can cross-build Windows binaries on Linux
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
ifeq ($(HOST_OS),linux)
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OS := windows
HOST_CROSS_ARCH := x86
Add 64-bit windows cross-compiles This is mostly the same as the existing 2ND_HOST / HOST_CROSS support. The interesting thing I did here was make x86 the 'first' architecture, and x86_64 the second. This way LOCAL_MULTILIB := first defaults to 32-bit windows modules. windows-x86/bin <- defaults to 32-bit executables windows-x86/lib <- 32-bit libraries, like before windows-x86/lib64 <- 64-bit libraries windows-x86/obj <- 32-bit intermediates windows-x86/obj64 <- 64-bit intermediates Then modules are registered with the names: host_cross_liblog <- 32-bit, like before host_cross_liblog_64 <- 64-bit Bug: 26957718 Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
2016-02-06 08:20:19 +08:00
HOST_CROSS_2ND_ARCH := x86_64
Remove unnecessary variables These are all either recently unused due to the removal of CFLAGS/etc, or have been exported by Soong and are no longer necessary. Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
2016-05-17 13:07:31 +08:00
2ND_HOST_CROSS_IS_64_BIT := true
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
ifeq ($(HOST_OS),)
$(error Unable to determine HOST_OS from uname -sm: $(UNAME)!)
endif
# HOST_ARCH
Support host multilib build 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
2014-04-18 01:03:35 +08:00
ifneq (,$(findstring x86_64,$(UNAME)))
Switch to 32-bit-by-default host multilib build. Also we don't need to force LLVM built from source, for we already force LLVM to be built as 32-bit. Bug: 13751317 Change-Id: Ifadf1988d28b60cb06316de50f5bdc1834f1acc0
2014-06-10 03:31:12 +08:00
HOST_ARCH := x86_64
HOST_2ND_ARCH := x86
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
HOST_IS_64_BIT := true
Clearly explain that 32-bit x86 is not supported Change-Id: I7f352fae8fa3742c61dc74e20aacd32254451bce
2015-03-21 02:39:00 +08:00
else
Detect `uname -m` == i686 as a 32-bit host Change-Id: I0350629ce6ea7a5f0224489bafc98bc190e70932 Test: UNAME from https://groups.google.com/d/msg/android-building/nGQna2xuW5s/eEcXSo9ZBgAJ
2016-06-30 03:26:53 +08:00
ifneq (,$(findstring i686,$(UNAME))$(findstring x86,$(UNAME)))
Clearly explain that 32-bit x86 is not supported Change-Id: I7f352fae8fa3742c61dc74e20aacd32254451bce
2015-03-21 02:39:00 +08:00
$(error Building on a 32-bit x86 host is not supported: $(UNAME)!)
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
BUILD_ARCH := $(HOST_ARCH)
Support host multilib build 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
2014-04-18 01:03:35 +08:00
BUILD_2ND_ARCH := $(HOST_2ND_ARCH)
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
ifeq ($(HOST_ARCH),)
$(error Unable to determine HOST_ARCH from uname -sm: $(UNAME)!)
endif
# the host build defaults to release, and it must be release or debug
ifeq ($(HOST_BUILD_TYPE),)
HOST_BUILD_TYPE := release
endif
ifneq ($(HOST_BUILD_TYPE),release)
ifneq ($(HOST_BUILD_TYPE),debug)
$(error HOST_BUILD_TYPE must be either release or debug, not '$(HOST_BUILD_TYPE)')
endif
endif
Support host multilib build 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
2014-04-18 01:03:35 +08:00
# We don't want to move all the prebuilt host tools to a $(HOST_OS)-x86_64 dir.
HOST_PREBUILT_ARCH := x86
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# This is the standard way to name a directory containing prebuilt host
# objects. E.g., prebuilt/$(HOST_PREBUILT_TAG)/cc
Fix prebuilts for target builds with USE_MINGW=1. USE_MINGW=1 mm didn't work in directories that contained target modules because the build system would use the Windows locations and extensions when trying to find the host GCC prebuilts. Windows is the target OS, not the OS we're building from. Change-Id: Ic994fed15388d0c7d393f71ba28fe7afdc659f5c
2015-05-05 03:44:44 +08:00
HOST_PREBUILT_TAG := $(BUILD_OS)-$(HOST_PREBUILT_ARCH)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
# TARGET_COPY_OUT_* are all relative to the staging directory, ie PRODUCT_OUT.
# Define them here so they can be used in product config files.
TARGET_COPY_OUT_SYSTEM := system
Add system_other partition, install odex files For AB devices, support flashing two system partitions for factory use. The normal system image on one partition, but without dex preopt. And a system_other image that just contains the odex files. The dex files will not be stripped out of the system image, in case the second system partition is wiped. Setting BOARD_USES_SYSTEM_OTHER_ODEX := true in the BoardConfig.mk enables this behavior. One can control which directories are placed in system_other by the SYSTEM_OTHER_ODEX_FILTER configuration variable. Currently we default to only copying only app and priv-app odexs. Bug: 29278988 Change-Id: I7f4e87da919e7dc6a89fd8c668193cd4e98631bc
2016-06-17 05:47:10 +08:00
TARGET_COPY_OUT_SYSTEM_OTHER := system_other
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_COPY_OUT_DATA := data
Refactor sanitized library on-disk layout - Make. This CL moves the location of ASAN-ified libraries on disk in the following manner: /data/lib* --> /data/asan/system/lib* /data/vendor/* --> /data/asan/vendor/* There are a couple of advantages to this, including better isolation from other components, and more transparent linker renaming and SELinux policies. Bug: 36574794 Bug: 36674745 Test: m -j40 && SANITIZE_TARGET="address" m -j40 and the device boots. All sanitized libraries are correctly located in /data/asan/*. Change-Id: Ic6ba8e43e31df2ea92b85fd60f572823b6883ba2
2017-03-30 06:32:04 +08:00
TARGET_COPY_OUT_ASAN := $(TARGET_COPY_OUT_DATA)/asan
Set up rules to build oem.img To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
2014-03-12 08:13:27 +08:00
TARGET_COPY_OUT_OEM := oem
Support to configure and build multiple custom images. Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
2015-03-13 09:30:39 +08:00
TARGET_COPY_OUT_ODM := odm
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_COPY_OUT_ROOT := root
TARGET_COPY_OUT_RECOVERY := recovery
Support to set up TARGET_COPY_OUT_VENDOR in board config. We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product config makefiiles we actually get the placeholders in PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its BoardConfig.mk. We substitute the placeholder with the real TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk. With this change, we can support building vendor stuff to system.img (the default) or a separate vendor.img. Bug: 16515152 Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
2014-07-24 11:20:49 +08:00
###########################################
# Define TARGET_COPY_OUT_VENDOR to a placeholder, for at this point
# we don't know if the device wants to build a separate vendor.img
# or just build vendor stuff into system.img.
# A device can set up TARGET_COPY_OUT_VENDOR to "vendor" in its
# BoardConfig.mk.
# We'll substitute with the real value after loading BoardConfig.mk.
_vendor_path_placeholder := ||VENDOR-PATH-PH||
TARGET_COPY_OUT_VENDOR := $(_vendor_path_placeholder)
###########################################
# Read the product specs so we can get TARGET_DEVICE and other
fix broken build rules for host VM.
2011-06-17 07:58:11 +08:00
# variables that we need in order to locate the output files.
include $(BUILD_SYSTEM)/product_config.mk
Turn dalvikvm host builds on by default when linux is the host OS. Previously host builds were only enabled under user and user-debug builds. This will make it easier for Androids to find out if they've inadvertently broken host compatibility in native code. Change-Id: Id1f2d5e189c4c1b6462fe03bab1b0f75e98a599c
2010-09-23 01:59:10 +08:00
Remove build variant "tests" Bug: 5368571 Now we have a phony target "tests" instead. The target can be built in any other build variant (eg userdebug). For example, "make PRODUCT-full-userdebug tests dist" will build and put the *-test-* zip file in the dist dir. The "tests" target will include all modules tagged as "tests" in addition to other modules in specific target out directories. Change-Id: I8383097380d8e6846c3e2107d6dd5f68788cfc39
2011-11-18 06:51:12 +08:00
build_variant := $(filter-out eng user userdebug,$(TARGET_BUILD_VARIANT))
fix broken build rules for host VM.
2011-06-17 07:58:11 +08:00
ifneq ($(build_variant)-$(words $(TARGET_BUILD_VARIANT)),-1)
$(warning bad TARGET_BUILD_VARIANT: $(TARGET_BUILD_VARIANT))
Remove build variant "tests" Bug: 5368571 Now we have a phony target "tests" instead. The target can be built in any other build variant (eg userdebug). For example, "make PRODUCT-full-userdebug tests dist" will build and put the *-test-* zip file in the dist dir. The "tests" target will include all modules tagged as "tests" in addition to other modules in specific target out directories. Change-Id: I8383097380d8e6846c3e2107d6dd5f68788cfc39
2011-11-18 06:51:12 +08:00
$(error must be empty or one of: eng user userdebug)
fix broken build rules for host VM.
2011-06-17 07:58:11 +08:00
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Default host module to 64-bit except for SDK builds. Set "HOST_PREFER_32_BIT := true" only if "sdk" or "win_sdk" is among the make command line goals, or it's a MinGW windows build, which only builds host SDK tools. Bug: 13751317 Change-Id: I8ec1a97a5d1af065a153b16523c2ee3434d0dd71
2014-09-03 06:11:20 +08:00
SDK_HOST_ARCH := x86
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
# Boards may be defined under $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)
# or under vendor/*/$(TARGET_DEVICE). Search in both places, but
# make sure only one exists.
# Real boards should always be associated with an OEM vendor.
board_config_mk := \
Sort more instances of wildcard and find Many of these may not make a difference in the output images, but it's a good idea to keep the make system as repeatable as possible. Change-Id: I31804b8ad5805148ed08be7426a242a16f4d0df3
2015-09-30 07:30:21 +08:00
$(strip $(sort $(wildcard \
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
$(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \
envsetup,product,ninja: enable symlink traversal When searching device, product, or hardware, allow find to follow symlinks. Add KATI_EMULATE_FIND=false to allow disabling the find emulator which changes findleaves.py behavior wrt symlinks. BUG=24605247 TEST=works with CL:783781 (without the find wrapper in that CL) Change-Id: Ia9d0e4add391a56f34828a09a6cec3f435ccc548
2015-10-07 10:40:11 +08:00
$(shell test -d device && find -L device -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \
$(shell test -d vendor && find -L vendor -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \
Sort more instances of wildcard and find Many of these may not make a difference in the output images, but it's a good idea to keep the make system as repeatable as possible. Change-Id: I31804b8ad5805148ed08be7426a242a16f4d0df3
2015-09-30 07:30:21 +08:00
)))
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
ifeq ($(board_config_mk),)
$(error No config file found for TARGET_DEVICE $(TARGET_DEVICE))
endif
ifneq ($(words $(board_config_mk)),1)
$(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk))
endif
include $(board_config_mk)
ifeq ($(TARGET_ARCH),)
$(error TARGET_ARCH not defined by board config: $(board_config_mk))
endif
Error out if MALLOC_IMPL is defined. Bug: http://b/26390299 Change-Id: Icd3ce6853c8207b1a9ce1f9d546a61d5b113f15a
2016-01-23 03:24:59 +08:00
ifneq ($(MALLOC_IMPL),)
$(warning *** Unsupported option MALLOC_IMPL defined by board config: $(board_config_mk).)
$(error Use `MALLOC_SVELTE := true` to configure jemalloc for low-memory)
endif
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))
board_config_mk :=
Support to set up TARGET_COPY_OUT_VENDOR in board config. We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product config makefiiles we actually get the placeholders in PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its BoardConfig.mk. We substitute the placeholder with the real TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk. With this change, we can support building vendor stuff to system.img (the default) or a separate vendor.img. Bug: 16515152 Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
2014-07-24 11:20:49 +08:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_VENDOR
ifeq ($(TARGET_COPY_OUT_VENDOR),$(_vendor_path_placeholder))
TARGET_COPY_OUT_VENDOR := system/vendor
else ifeq ($(filter vendor system/vendor,$(TARGET_COPY_OUT_VENDOR)),)
$(error TARGET_COPY_OUT_VENDOR must be either 'vendor' or 'system/vendor', seeing '$(TARGET_COPY_OUT_VENDOR)'.)
endif
PRODUCT_COPY_FILES := $(subst $(_vendor_path_placeholder),$(TARGET_COPY_OUT_VENDOR),$(PRODUCT_COPY_FILES))
Clean up vendor image handling Standardize symlinking /system/vendor -> /vendor for aosp_* devices, since some /vendor binaries still use /system/vendor/... paths. Support using a prebuilt vendor image and including it into all the normal packaging steps. Bug: 28987532 Change-Id: I27040e8a8d1df0777e16cd1e3c3a9f1b28695e96
2016-06-18 05:07:37 +08:00
BOARD_USES_VENDORIMAGE :=
ifdef BOARD_PREBUILT_VENDORIMAGE
BOARD_USES_VENDORIMAGE := true
endif
ifdef BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE
BOARD_USES_VENDORIMAGE := true
endif
ifeq ($(TARGET_COPY_OUT_VENDOR),vendor)
BOARD_USES_VENDORIMAGE := true
else ifdef BOARD_USES_VENDORIMAGE
$(error TARGET_COPY_OUT_VENDOR must be set to 'vendor' to use a vendor image)
endif
Support to set up TARGET_COPY_OUT_VENDOR in board config. We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product config makefiiles we actually get the placeholders in PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its BoardConfig.mk. We substitute the placeholder with the real TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk. With this change, we can support building vendor stuff to system.img (the default) or a separate vendor.img. Bug: 16515152 Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
2014-07-24 11:20:49 +08:00
###########################################
TARGET_RECOVERY_UPDATER_LIBS should not be used with AB updates Also mark these variables as readonly so that later Android.mk cannot change them. Bug: 33607778 Test: build/tools/kati_all_products.sh -j12 Change-Id: I5f9a4df02bfdfd56549728f074bbb3fc251edb3d
2017-01-05 09:16:09 +08:00
# Ensure that only TARGET_RECOVERY_UPDATER_LIBS *or* AB_OTA_UPDATER is set.
TARGET_RECOVERY_UPDATER_LIBS ?=
AB_OTA_UPDATER ?=
.KATI_READONLY := TARGET_RECOVERY_UPDATER_LIBS AB_OTA_UPDATER
ifeq ($(AB_OTA_UPDATER),true)
ifneq ($(strip $(TARGET_RECOVERY_UPDATER_LIBS)),)
$(error Do not use TARGET_RECOVERY_UPDATER_LIBS when using AB_OTA_UPDATER)
endif
endif
Support to set up TARGET_COPY_OUT_VENDOR in board config. We first define TARGET_COPY_OUT_VENDOR as a placeholder. In product config makefiiles we actually get the placeholders in PRODUCT_COPY_FILES. A device can set up TARGET_COPY_OUT_VENDOR in its BoardConfig.mk. We substitute the placeholder with the real TARGET_COPY_OUT_VENDOR value after loading the BoardConfig.mk. With this change, we can support building vendor stuff to system.img (the default) or a separate vendor.img. Bug: 16515152 Change-Id: I5b601d7a8b34fe032a1bac02aa5c204a3765691d
2014-07-24 11:20:49 +08:00
Ensure that BOARD_VNDK_VERSION is current BOARD_VNDK_VERSION controls which version of the VNDK is used for the build. We only support compiling against the current VNDK, and we don't support installing old prebuilt VNDK libraries yet, so ensure this variable is set to "current". Once we support installing old prebuilt VNDK libraries, we'll also need to disable building modules that use the VNDK. Test: build-aosp_arm.ninja is the same before/after Test: Ensure there are no boards that set BOARD_VNDK_VERSION Test: Set BOARD_VNDK_VERSION := invalid Change-Id: Ic26c9f44e356a0734f522b4538cb866d5b901d43
2017-03-20 04:22:45 +08:00
# Check BOARD_VNDK_VERSION
ifdef BOARD_VNDK_VERSION
ifneq ($(BOARD_VNDK_VERSION),current)
$(error BOARD_VNDK_VERSION: Only "current" is implemented)
endif
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# ---------------------------------------------------------------
# Set up configuration for target machine.
# The following must be set:
# TARGET_OS = { linux }
MIPS support to *.mk files and envsetup.sh Change-Id: Iba4d046e3202524b29cfe32980927f8cc0aa8496 Signed-off-by: Chris Dearman <chris@mips.com> Signed-off-by: Raghu Gandham <raghu@mips.com>
2012-07-26 10:57:22 +08:00
# TARGET_ARCH = { arm | x86 | mips }
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OS := linux
MIPS support to *.mk files and envsetup.sh Change-Id: Iba4d046e3202524b29cfe32980927f8cc0aa8496 Signed-off-by: Chris Dearman <chris@mips.com> Signed-off-by: Raghu Gandham <raghu@mips.com>
2012-07-26 10:57:22 +08:00
# TARGET_ARCH should be set by BoardConfig.mk and will be checked later
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
ifneq ($(filter %64,$(TARGET_ARCH)),)
TARGET_IS_64_BIT := true
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# the target build type defaults to release
ifneq ($(TARGET_BUILD_TYPE),debug)
TARGET_BUILD_TYPE := release
endif
# ---------------------------------------------------------------
# figure out the output directories
ifeq (,$(strip $(OUT_DIR)))
Set OUT_DIR based on a common base path Change-Id: I2c4ba8b101d4d186ed4b371b9d07b3bcf75bbcc9 Author: Jean-Baptiste Queru<jbq@google.com> Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
2011-12-07 02:29:46 +08:00
ifeq (,$(strip $(OUT_DIR_COMMON_BASE)))
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
OUT_DIR := $(TOPDIR)out
Set OUT_DIR based on a common base path Change-Id: I2c4ba8b101d4d186ed4b371b9d07b3bcf75bbcc9 Author: Jean-Baptiste Queru<jbq@google.com> Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
2011-12-07 02:29:46 +08:00
else
OUT_DIR := $(OUT_DIR_COMMON_BASE)/$(notdir $(PWD))
endif
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
Add Soong tools to PATH Change-Id: I8f8649106df4ba7cefbfa37a724ebe0635d90b76
2016-05-28 06:15:47 +08:00
SOONG_OUT_DIR := $(OUT_DIR)/soong
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
DEBUG_OUT_DIR := $(OUT_DIR)/debug
# Move the host or target under the debug/ directory
# if necessary.
TARGET_OUT_ROOT_release := $(OUT_DIR)/target
TARGET_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/target
TARGET_OUT_ROOT := $(TARGET_OUT_ROOT_$(TARGET_BUILD_TYPE))
HOST_OUT_ROOT_release := $(OUT_DIR)/host
HOST_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/host
HOST_OUT_ROOT := $(HOST_OUT_ROOT_$(HOST_BUILD_TYPE))
Support host multilib build 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
2014-04-18 01:03:35 +08:00
# We want to avoid two host bin directories in multilib build.
HOST_OUT_release := $(HOST_OUT_ROOT_release)/$(HOST_OS)-$(HOST_PREBUILT_ARCH)
HOST_OUT_debug := $(HOST_OUT_ROOT_debug)/$(HOST_OS)-$(HOST_PREBUILT_ARCH)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
HOST_OUT := $(HOST_OUT_$(HOST_BUILD_TYPE))
Add Soong tools to PATH Change-Id: I8f8649106df4ba7cefbfa37a724ebe0635d90b76
2016-05-28 06:15:47 +08:00
SOONG_HOST_OUT := $(SOONG_OUT_DIR)/host/$(HOST_OS)-$(HOST_PREBUILT_ARCH)
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
# TODO: remove
BUILD_OUT := $(HOST_OUT)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OUT_release := $(HOST_OUT_ROOT_release)/windows-$(HOST_PREBUILT_ARCH)
HOST_CROSS_OUT_debug := $(HOST_OUT_ROOT_debug)/windows-$(HOST_PREBUILT_ARCH)
HOST_CROSS_OUT := $(HOST_CROSS_OUT_$(HOST_BUILD_TYPE))
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
Remove the simulator target from all makefiles. Bug: 5010576 Change-Id: Ie814f4c8d3aa1e7cc7f5735822ab25542f36cf62
2011-07-12 13:11:46 +08:00
TARGET_PRODUCT_OUT_ROOT := $(TARGET_OUT_ROOT)/product
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_COMMON_OUT_ROOT := $(TARGET_OUT_ROOT)/common
HOST_COMMON_OUT_ROOT := $(HOST_OUT_ROOT)/common
PRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE)
OUT_DOCS := $(TARGET_COMMON_OUT_ROOT)/docs
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
BUILD_OUT_EXECUTABLES := $(BUILD_OUT)/bin
Add Soong tools to PATH Change-Id: I8f8649106df4ba7cefbfa37a724ebe0635d90b76
2016-05-28 06:15:47 +08:00
SOONG_HOST_OUT_EXECUTABLES := $(SOONG_HOST_OUT)/bin
Support building Windows SDK under Linux. - envsetup.mk & config.mk: we define a new BUILD_OS and a minimal set of things like BUILD_OUT to be able to use some local tools when doing cross-compilation. This allows us to use the Linux version of ACP when cross-compiling the tools to Windows. - Makfile: include windows_sdk.mk when needed to build a Windows SDK. - main.mk: support a win_sdk target (e.g. PRODUCT-sdk-win_sdk) (Merge master Change I9d08d0df)
2010-04-17 08:50:09 +08:00
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
HOST_OUT_EXECUTABLES := $(HOST_OUT)/bin
More consistent host library path in multilib build. In 64-bit multilib host build, changed from 32-bit lib: out/host/<platform>/lib32 64-bit lib: out/host/<platform>/lib to 32-bit lib: out/host/<platform>/lib 64-bit lib: out/host/<platform>/lib64 . That way the host library path is consistent with the multilib target build's. Also with this change prebuilt 32-bit libraries can be reused in 64-bit host build as 2nd arch binaries. (With previous setup, they can't be used because they have rpath ../lib in it while the 2nd arch library path needs ../lib32. Change-Id: I020199d0c7dd52cdc8dcb7d3a1d22cd6178672e1
2014-07-01 08:06:21 +08:00
HOST_OUT_SHARED_LIBRARIES := $(HOST_OUT)/lib64
Define a class for renderscript bitcode files These have been using SHARED_LIBRARIES, but aren't elf shared libraries. Continue installing them to /system/lib[64], but do not apply any other normal shared library logic to them. Change-Id: I3055ff86bb7b116c7107c41578ed6f0f304b1cf1
2016-02-13 16:19:40 +08:00
HOST_OUT_RENDERSCRIPT_BITCODE := $(HOST_OUT_SHARED_LIBRARIES)
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
HOST_OUT_JAVA_LIBRARIES := $(HOST_OUT)/framework
AI 145618: am: CL 145333 Cloned from CL 144759 by 'g4 patch'. Original change by joeo@abreu on 2009/04/06 19:54:13. Implement SDK add-ons in the build system. - Add an option to use the standard javadoc doclet instead of droiddoc, since droiddocs non-sdk templates aren't ready for prime time. - Add the notion of a stubs for a library. It's only implemented for java libraries, but when we do native libraries in the NDK or sdk-addons, it will work there too. Original author: joeo Merged from: //branches/cupcake/... Automated import of CL 145618
2009-04-10 10:31:12 +08:00
HOST_OUT_SDK_ADDON := $(HOST_OUT)/sdk_addon
Add NATIVE_TESTS class, move host native tests Host native tests have been getting installed into out/host/linux-x86/bin/..., but this pollutes the bin directory with a lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we need to have different names with different suffixes. This causes problems when tests expect to be named something specific (like gtest). It's also convenient to store test data next to the test itself. So with this change, native tests will be installed in out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM) just like target tests get installed into /data/nativetest[64]. Implement this using a new NATIVE_TESTS class, which is like EXECUTABLES, but sets up the install path differently, and configures the rpath to load shared libraries with the proper relative path. LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it will default to $(LOCAL_MODULE). This way multiple related tests can be grouped together. Target native tests also use NATIVE_TESTS now, but nothing should change other than LOCAL_MODULE_RELATIVE_PATH can be used. Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-03 05:54:51 +08:00
HOST_OUT_NATIVE_TESTS := $(HOST_OUT)/nativetest64
Implement path-based enabling of code coverage. Native coverage is enabled by setting NATIVE_COVERAGE to true and specifying a list of paths in the COVERAGE_PATHS environment variable. Files are exported to a zip file in the target out directory. Change-Id: I66a2ddd88e849bec1cc0cdae1b51fe18a007e2c3
2016-09-13 04:56:50 +08:00
HOST_OUT_COVERAGE := $(HOST_OUT)/coverage
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OUT_EXECUTABLES := $(HOST_CROSS_OUT)/bin
HOST_CROSS_OUT_SHARED_LIBRARIES := $(HOST_CROSS_OUT)/lib
Add NATIVE_TESTS class, move host native tests Host native tests have been getting installed into out/host/linux-x86/bin/..., but this pollutes the bin directory with a lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we need to have different names with different suffixes. This causes problems when tests expect to be named something specific (like gtest). It's also convenient to store test data next to the test itself. So with this change, native tests will be installed in out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM) just like target tests get installed into /data/nativetest[64]. Implement this using a new NATIVE_TESTS class, which is like EXECUTABLES, but sets up the install path differently, and configures the rpath to load shared libraries with the proper relative path. LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it will default to $(LOCAL_MODULE). This way multiple related tests can be grouped together. Target native tests also use NATIVE_TESTS now, but nothing should change other than LOCAL_MODULE_RELATIVE_PATH can be used. Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-03 05:54:51 +08:00
HOST_CROSS_OUT_NATIVE_TESTS := $(HOST_CROSS_OUT)/nativetest
Implement path-based enabling of code coverage. Native coverage is enabled by setting NATIVE_COVERAGE to true and specifying a list of paths in the COVERAGE_PATHS environment variable. Files are exported to a zip file in the target out directory. Change-Id: I66a2ddd88e849bec1cc0cdae1b51fe18a007e2c3
2016-09-13 04:56:50 +08:00
HOST_CROSS_OUT_COVERAGE := $(HOST_CROSS_OUT)/coverage
Output *TS testcases to common testcase folders. Aggregates the different *TS testcases into two common folders, one under each the host and product hierarchies. Bug: 34715822 Test: `make cts -j` and checked the contents of both: out/host/linux-x86/testcases/ & out/host/linux-x86/cts/android-cts/testcases/ Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
2017-01-26 07:11:55 +08:00
HOST_OUT_TESTCASES := $(HOST_OUT)/testcases
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
HOST_OUT_INTERMEDIATES := $(HOST_OUT)/obj
HOST_OUT_INTERMEDIATE_LIBRARIES := $(HOST_OUT_INTERMEDIATES)/lib
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
HOST_OUT_NOTICE_FILES := $(HOST_OUT_INTERMEDIATES)/NOTICE_FILES
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
HOST_OUT_COMMON_INTERMEDIATES := $(HOST_COMMON_OUT_ROOT)/obj
Support host phony package. Bug: 11467421 Change-Id: I146387aecc57aaabbbb81f8c8bc9b5c9a5e81f05
2013-11-14 07:56:18 +08:00
HOST_OUT_FAKE := $(HOST_OUT)/fake_packages
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
introduce AUX build class of targets AUX is a new class, similar to TARGET While TARGET defines toolchain for Application Processors AUX is defining toolchains for arbitrary utility cores (DSPs, GPUs, MCUs, etc). This allows building of non-android sources as part of Android tree and avoid using prebuilts if source code is avaliable Bug: 29635686 Change-Id: Ie755ea054b16c3e86369f5fb2ba6eb0b384af77f Signed-off-by: Alexey Polyudov <apolyudov@google.com>
2016-08-02 08:41:49 +08:00
# Nano environment config
include $(BUILD_SYSTEM)/aux_config.mk
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OUT_INTERMEDIATES := $(HOST_CROSS_OUT)/obj
HOST_CROSS_OUT_INTERMEDIATE_LIBRARIES := $(HOST_CROSS_OUT_INTERMEDIATES)/lib
HOST_CROSS_OUT_NOTICE_FILES := $(HOST_CROSS_OUT_INTERMEDIATES)/NOTICE_FILES
add new gen/ directory for generated sources Allow modules to generate source into $OUT/gen, which will then be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as necessary. This allows a single build rule invocation that includes generated source to build for the first and second architectures. Modules will need to change calls to local-intermediates-dir into local-generated-sources-dir. Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
2014-01-25 15:17:21 +08:00
HOST_OUT_GEN := $(HOST_OUT)/gen
HOST_OUT_COMMON_GEN := $(HOST_COMMON_OUT_ROOT)/gen
Add HOST_CROSS_OS 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
2015-08-15 03:59:50 +08:00
HOST_CROSS_OUT_GEN := $(HOST_CROSS_OUT)/gen
Support host multilib build 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
2014-04-18 01:03:35 +08:00
# Out for HOST_2ND_ARCH
HOST_2ND_ARCH_VAR_PREFIX := 2ND_
HOST_2ND_ARCH_MODULE_SUFFIX := _32
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_INTERMEDIATES := $(HOST_OUT)/obj32
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_INTERMEDIATE_LIBRARIES := $($(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_INTERMEDIATES)/lib
Add HOST_PREFER_32_BIT to support 32-bit-by-default multilib build We already support pure 32-bit and 64-bit-by-default multilib build. With HOST_PREFER_32_BIT we can build 32-bit-by-default multilib build. This will be lest disruptive during the period we transition to 64-bit-by-default. Bug: 13751317 Change-Id: I0d56ce4abbe4afeaacfd70d709f6a349791c0722
2014-05-21 05:43:51 +08:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_SHARED_LIBRARIES := $(HOST_OUT)/lib
Support host multilib build 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
2014-04-18 01:03:35 +08:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_EXECUTABLES := $(HOST_OUT_EXECUTABLES)
Make Windows a non-multilib target. We don't have a toolchain for 64-bit windows. This allows running `USE_MINGW=1 mm` in a directory that has a host module with LOCAL_MULTILIB := both. Change-Id: I31f981b38fb80b0d6582bab0a4bd580a3c654c91
2015-05-05 09:17:52 +08:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_JAVA_LIBRARIES := $(HOST_OUT_JAVA_LIBRARIES)
Add NATIVE_TESTS class, move host native tests Host native tests have been getting installed into out/host/linux-x86/bin/..., but this pollutes the bin directory with a lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we need to have different names with different suffixes. This causes problems when tests expect to be named something specific (like gtest). It's also convenient to store test data next to the test itself. So with this change, native tests will be installed in out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM) just like target tests get installed into /data/nativetest[64]. Implement this using a new NATIVE_TESTS class, which is like EXECUTABLES, but sets up the install path differently, and configures the rpath to load shared libraries with the proper relative path. LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it will default to $(LOCAL_MODULE). This way multiple related tests can be grouped together. Target native tests also use NATIVE_TESTS now, but nothing should change other than LOCAL_MODULE_RELATIVE_PATH can be used. Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-03 05:54:51 +08:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_NATIVE_TESTS := $(HOST_OUT)/nativetest
Output *TS testcases to common testcase folders. Aggregates the different *TS testcases into two common folders, one under each the host and product hierarchies. Bug: 34715822 Test: `make cts -j` and checked the contents of both: out/host/linux-x86/testcases/ & out/host/linux-x86/cts/android-cts/testcases/ Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
2017-01-26 07:11:55 +08:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_TESTCASES := $(HOST_OUT_TESTCASES)
Support host multilib build 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
2014-04-18 01:03:35 +08:00
Add global variable HOST_LIBRARY_PATH. With multilib host build, the build system installs host shared libraries to different directories depending on a library's bitness: - HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit; - 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit; - If you don't care the bitness of the libraries and just want whatever version the librareies are built by default, use HOST_LIBRARY_PATH. Bug:13751317 Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
2014-06-11 03:04:56 +08:00
# The default host library path.
# It always points to the path where we build libraries in the default bitness.
Fix HOST_LIBRARY_PATH. Since we switched to $(HOST_OUT)/lib64 for 64-bit libraries and $(HOST_OUT)/lib for 32-bit libraries. Change-Id: Ie43bc03c37e2ac8542412a7543a6af5d60c6f725
2014-08-15 02:03:56 +08:00
HOST_LIBRARY_PATH := $(HOST_OUT_SHARED_LIBRARIES)
Support host multilib build 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
2014-04-18 01:03:35 +08:00
Add 64-bit windows cross-compiles This is mostly the same as the existing 2ND_HOST / HOST_CROSS support. The interesting thing I did here was make x86 the 'first' architecture, and x86_64 the second. This way LOCAL_MULTILIB := first defaults to 32-bit windows modules. windows-x86/bin <- defaults to 32-bit executables windows-x86/lib <- 32-bit libraries, like before windows-x86/lib64 <- 64-bit libraries windows-x86/obj <- 32-bit intermediates windows-x86/obj64 <- 64-bit intermediates Then modules are registered with the names: host_cross_liblog <- 32-bit, like before host_cross_liblog_64 <- 64-bit Bug: 26957718 Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
2016-02-06 08:20:19 +08:00
# Out for HOST_CROSS_2ND_ARCH
HOST_CROSS_2ND_ARCH_VAR_PREFIX := 2ND_
HOST_CROSS_2ND_ARCH_MODULE_SUFFIX := _64
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_INTERMEDIATES := $(HOST_CROSS_OUT)/obj64
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_INTERMEDIATE_LIBRARIES := $($(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_INTERMEDIATES)/lib
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_SHARED_LIBRARIES := $(HOST_CROSS_OUT)/lib64
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_EXECUTABLES := $(HOST_CROSS_OUT_EXECUTABLES)
Add NATIVE_TESTS class, move host native tests Host native tests have been getting installed into out/host/linux-x86/bin/..., but this pollutes the bin directory with a lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we need to have different names with different suffixes. This causes problems when tests expect to be named something specific (like gtest). It's also convenient to store test data next to the test itself. So with this change, native tests will be installed in out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM) just like target tests get installed into /data/nativetest[64]. Implement this using a new NATIVE_TESTS class, which is like EXECUTABLES, but sets up the install path differently, and configures the rpath to load shared libraries with the proper relative path. LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it will default to $(LOCAL_MODULE). This way multiple related tests can be grouped together. Target native tests also use NATIVE_TESTS now, but nothing should change other than LOCAL_MODULE_RELATIVE_PATH can be used. Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-03 05:54:51 +08:00
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_NATIVE_TESTS := $(HOST_CROSS_OUT)/nativetest64
Add 64-bit windows cross-compiles This is mostly the same as the existing 2ND_HOST / HOST_CROSS support. The interesting thing I did here was make x86 the 'first' architecture, and x86_64 the second. This way LOCAL_MULTILIB := first defaults to 32-bit windows modules. windows-x86/bin <- defaults to 32-bit executables windows-x86/lib <- 32-bit libraries, like before windows-x86/lib64 <- 64-bit libraries windows-x86/obj <- 32-bit intermediates windows-x86/obj64 <- 64-bit intermediates Then modules are registered with the names: host_cross_liblog <- 32-bit, like before host_cross_liblog_64 <- 64-bit Bug: 26957718 Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
2016-02-06 08:20:19 +08:00
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OUT_INTERMEDIATES := $(PRODUCT_OUT)/obj
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_HEADERS := $(TARGET_OUT_INTERMEDIATES)/include
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OUT_INTERMEDIATE_LIBRARIES := $(TARGET_OUT_INTERMEDIATES)/lib
TARGET_OUT_COMMON_INTERMEDIATES := $(TARGET_COMMON_OUT_ROOT)/obj
add new gen/ directory for generated sources Allow modules to generate source into $OUT/gen, which will then be copied into $OUT/obj and $OUT/obj_$(TARGET_2ND_ARCH) as necessary. This allows a single build rule invocation that includes generated source to build for the first and second architectures. Modules will need to change calls to local-intermediates-dir into local-generated-sources-dir. Change-Id: I62504bad9454b3d9fde7b84ab9f0a487a2ecf0bf
2014-01-25 15:17:21 +08:00
TARGET_OUT_GEN := $(PRODUCT_OUT)/gen
TARGET_OUT_COMMON_GEN := $(TARGET_COMMON_OUT_ROOT)/gen
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_OUT := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_SYSTEM)
Add support of SANITIZE_TARGET='address coverage' for fuzzing. Also, add trace-cmp instrumentation to fuzz_test and host_fuzz_test. Bug: 22850550 Change-Id: Ifff7b8be693ae991feb0a64e19439370a19b2748
2015-09-19 02:54:43 +08:00
ifneq ($(filter address,$(SANITIZE_TARGET)),)
Refactor sanitized library on-disk layout - Make. This CL moves the location of ASAN-ified libraries on disk in the following manner: /data/lib* --> /data/asan/system/lib* /data/vendor/* --> /data/asan/vendor/* There are a couple of advantages to this, including better isolation from other components, and more transparent linker renaming and SELinux policies. Bug: 36574794 Bug: 36674745 Test: m -j40 && SANITIZE_TARGET="address" m -j40 and the device boots. All sanitized libraries are correctly located in /data/asan/*. Change-Id: Ic6ba8e43e31df2ea92b85fd60f572823b6883ba2
2017-03-30 06:32:04 +08:00
target_out_shared_libraries_base := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_ASAN)/system
With SANITIZE_TARGET, move shared libraries to /data. A fully (or even mostly) asan-instrumented device will have 2 copies of each shared library, which might not fit on system partition. Moving instrumented libraries to /data. Bug: 21785137 Change-Id: I64184261da2eb24a1382c67e4931c34a5a38b3c0
2015-06-12 08:32:31 +08:00
else
target_out_shared_libraries_base := $(TARGET_OUT)
endif
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_EXECUTABLES := $(TARGET_OUT)/bin
TARGET_OUT_OPTIONAL_EXECUTABLES := $(TARGET_OUT)/xbin
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
ifeq ($(TARGET_IS_64_BIT),true)
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
# /system/lib always contains 32-bit libraries,
# and /system/lib64 (if present) always contains 64-bit libraries.
With SANITIZE_TARGET, move shared libraries to /data. A fully (or even mostly) asan-instrumented device will have 2 copies of each shared library, which might not fit on system partition. Moving instrumented libraries to /data. Bug: 21785137 Change-Id: I64184261da2eb24a1382c67e4931c34a5a38b3c0
2015-06-12 08:32:31 +08:00
TARGET_OUT_SHARED_LIBRARIES := $(target_out_shared_libraries_base)/lib64
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
else
With SANITIZE_TARGET, move shared libraries to /data. A fully (or even mostly) asan-instrumented device will have 2 copies of each shared library, which might not fit on system partition. Moving instrumented libraries to /data. Bug: 21785137 Change-Id: I64184261da2eb24a1382c67e4931c34a5a38b3c0
2015-06-12 08:32:31 +08:00
TARGET_OUT_SHARED_LIBRARIES := $(target_out_shared_libraries_base)/lib
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
endif
Define a class for renderscript bitcode files These have been using SHARED_LIBRARIES, but aren't elf shared libraries. Continue installing them to /system/lib[64], but do not apply any other normal shared library logic to them. Change-Id: I3055ff86bb7b116c7107c41578ed6f0f304b1cf1
2016-02-13 16:19:40 +08:00
TARGET_OUT_RENDERSCRIPT_BITCODE := $(TARGET_OUT_SHARED_LIBRARIES)
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_JAVA_LIBRARIES := $(TARGET_OUT)/framework
TARGET_OUT_APPS := $(TARGET_OUT)/app
Install to TARGET_OUT_APPS_PRIVILEGED if LOCAL_PRIVILEGED_MODULE is true Change-Id: I268b8652f18034aa3fdd3126ebf6196f78c4bbb2
2013-05-09 06:49:08 +08:00
TARGET_OUT_APPS_PRIVILEGED := $(TARGET_OUT)/priv-app
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OUT_KEYLAYOUT := $(TARGET_OUT)/usr/keylayout
TARGET_OUT_KEYCHARS := $(TARGET_OUT)/usr/keychars
TARGET_OUT_ETC := $(TARGET_OUT)/etc
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_NOTICE_FILES := $(TARGET_OUT_INTERMEDIATES)/NOTICE_FILES
core: Make fake packages have real installed files for proper dependencies Change-Id: I3145440eea0fbbd8ba22a2b3b0511f4c18f90eca Signed-off-by: Dima Zavin <dima@android.com>
2010-09-28 08:37:17 +08:00
TARGET_OUT_FAKE := $(PRODUCT_OUT)/fake_packages
Output *TS testcases to common testcase folders. Aggregates the different *TS testcases into two common folders, one under each the host and product hierarchies. Bug: 34715822 Test: `make cts -j` and checked the contents of both: out/host/linux-x86/testcases/ & out/host/linux-x86/cts/android-cts/testcases/ Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
2017-01-26 07:11:55 +08:00
TARGET_OUT_TESTCASES := $(PRODUCT_OUT)/testcases
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add system_other partition, install odex files For AB devices, support flashing two system partitions for factory use. The normal system image on one partition, but without dex preopt. And a system_other image that just contains the odex files. The dex files will not be stripped out of the system image, in case the second system partition is wiped. Setting BOARD_USES_SYSTEM_OTHER_ODEX := true in the BoardConfig.mk enables this behavior. One can control which directories are placed in system_other by the SYSTEM_OTHER_ODEX_FILTER configuration variable. Currently we default to only copying only app and priv-app odexs. Bug: 29278988 Change-Id: I7f4e87da919e7dc6a89fd8c668193cd4e98631bc
2016-06-17 05:47:10 +08:00
TARGET_OUT_SYSTEM_OTHER := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_SYSTEM_OTHER)
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
2013-12-28 03:09:36 +08:00
# Out for TARGET_2ND_ARCH
Add global variable HOST_LIBRARY_PATH. With multilib host build, the build system installs host shared libraries to different directories depending on a library's bitness: - HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit; - 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit; - If you don't care the bitness of the libraries and just want whatever version the librareies are built by default, use HOST_LIBRARY_PATH. Bug:13751317 Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
2014-06-11 03:04:56 +08:00
TARGET_2ND_ARCH_VAR_PREFIX := $(HOST_2ND_ARCH_VAR_PREFIX)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
# With this you can reference the arm binary translation library with libfoo_arm in PRODUCT_PACKAGES.
TARGET_2ND_ARCH_MODULE_SUFFIX := _$(TARGET_2ND_ARCH)
else
Add global variable HOST_LIBRARY_PATH. With multilib host build, the build system installs host shared libraries to different directories depending on a library's bitness: - HOST_OUT_SHARED_LIBRARIES points to the library path of 64-bit; - 2ND_HOST_OUT_SHARED_LIBRARIES points to the library path of 32-bit; - If you don't care the bitness of the libraries and just want whatever version the librareies are built by default, use HOST_LIBRARY_PATH. Bug:13751317 Change-Id:Id4c818941dc4ea35d795767c76f698529bd6aebb
2014-06-11 03:04:56 +08:00
TARGET_2ND_ARCH_MODULE_SUFFIX := $(HOST_2ND_ARCH_MODULE_SUFFIX)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +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
2013-12-28 03:09:36 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_INTERMEDIATES := $(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_INTERMEDIATE_LIBRARIES := $($(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_INTERMEDIATES)/lib
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES := $(target_out_shared_libraries_base)/lib/$(TARGET_2ND_ARCH)
else
With SANITIZE_TARGET, move shared libraries to /data. A fully (or even mostly) asan-instrumented device will have 2 copies of each shared library, which might not fit on system partition. Moving instrumented libraries to /data. Bug: 21785137 Change-Id: I64184261da2eb24a1382c67e4931c34a5a38b3c0
2015-06-12 08:32:31 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES := $(target_out_shared_libraries_base)/lib
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
endif
Define a class for renderscript bitcode files These have been using SHARED_LIBRARIES, but aren't elf shared libraries. Continue installing them to /system/lib[64], but do not apply any other normal shared library logic to them. Change-Id: I3055ff86bb7b116c7107c41578ed6f0f304b1cf1
2016-02-13 16:19:40 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_RENDERSCRIPT_BITCODE := $($(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES)
Support to build executables for TARGET_2ND_ARCH By default, an executable is built for TARGET_ARCH. To build it for TARGET_2ND_ARCH in a 64bit product, use: LOCAL_32BIT_ONLY := true To skip a module for TARGET_2ND_ARCH, use: LOCAL_NO_2ND_ARCH := true Bug: 11654773 Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
2014-01-18 08:17:28 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_EXECUTABLES := $(TARGET_OUT_EXECUTABLES)
Add 2nd arch directories for apps Apps built for 2nd arch install in the same directories as when built for the 1st arch. Change-Id: Ib1d950e186eef88212b44d04e6bc6c30a3d56155
2014-01-25 05:37:07 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_APPS := $(TARGET_OUT_APPS)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_APPS_PRIVILEGED := $(TARGET_OUT_APPS_PRIVILEGED)
Output *TS testcases to common testcase folders. Aggregates the different *TS testcases into two common folders, one under each the host and product hierarchies. Bug: 34715822 Test: `make cts -j` and checked the contents of both: out/host/linux-x86/testcases/ & out/host/linux-x86/cts/android-cts/testcases/ Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
2017-01-26 07:11:55 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_TESTCASES := $(TARGET_OUT_TESTCASES)
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
2013-12-28 03:09:36 +08:00
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_OUT_DATA := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_DATA)
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_DATA_EXECUTABLES := $(TARGET_OUT_EXECUTABLES)
TARGET_OUT_DATA_SHARED_LIBRARIES := $(TARGET_OUT_SHARED_LIBRARIES)
TARGET_OUT_DATA_JAVA_LIBRARIES := $(TARGET_OUT_DATA)/framework
TARGET_OUT_DATA_APPS := $(TARGET_OUT_DATA)/app
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OUT_DATA_KEYLAYOUT := $(TARGET_OUT_KEYLAYOUT)
TARGET_OUT_DATA_KEYCHARS := $(TARGET_OUT_KEYCHARS)
TARGET_OUT_DATA_ETC := $(TARGET_OUT_ETC)
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
ifeq ($(TARGET_IS_64_BIT),true)
TARGET_OUT_DATA_NATIVE_TESTS := $(TARGET_OUT_DATA)/nativetest64
Benchmark have their own folder Benchmark tests use a separate folder from native tests. Bug: 27465556 Change-Id: Ife0f43062e36ffc856f41683ddc4d91a7787333e
2016-04-12 17:22:06 +08:00
TARGET_OUT_DATA_METRIC_TESTS := $(TARGET_OUT_DATA)/benchmarktest64
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
else
Flags common for native tests With the CL, "include $(BUILD_NATIVE_TEST)" to build native test; "include $(BUILD_HOST_NATIVE_TEST)" to build a host native test. Change-Id: Icdbbcf906cd4c5c35e65962897490052cd051102
2010-07-21 02:08:47 +08:00
TARGET_OUT_DATA_NATIVE_TESTS := $(TARGET_OUT_DATA)/nativetest
Benchmark have their own folder Benchmark tests use a separate folder from native tests. Bug: 27465556 Change-Id: Ife0f43062e36ffc856f41683ddc4d91a7787333e
2016-04-12 17:22:06 +08:00
TARGET_OUT_DATA_METRIC_TESTS := $(TARGET_OUT_DATA)/benchmarktest
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
endif
add a fake data target. (cherry picked from commit 3ba7baf14875d3cd360006be7dffe7e4e0cf1882) Change-Id: I691d4dda65437d3f57e77ed207da406fd1f53355
2012-07-14 04:47:09 +08:00
TARGET_OUT_DATA_FAKE := $(TARGET_OUT_DATA)/fake_packages
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_EXECUTABLES := $(TARGET_OUT_DATA_EXECUTABLES)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_SHARED_LIBRARIES := $($(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES)
Add 2nd arch directories for apps Apps built for 2nd arch install in the same directories as when built for the 1st arch. Change-Id: Ib1d950e186eef88212b44d04e6bc6c30a3d56155
2014-01-25 05:37:07 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_APPS := $(TARGET_OUT_DATA_APPS)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_NATIVE_TESTS := $(TARGET_OUT_DATA)/nativetest/$(TARGET_2ND_ARCH)
resolve merge conflicts of bc3720c to nyc-dev-plus-aosp Change-Id: I2372a61a39131ede33cda95afc3c3ddd19e542f0
2016-04-13 04:06:20 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_METRIC_TESTS := $(TARGET_OUT_DATA)/benchmarktest/$(TARGET_2ND_ARCH)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
else
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_NATIVE_TESTS := $(TARGET_OUT_DATA)/nativetest
Benchmark have their own folder Benchmark tests use a separate folder from native tests. Bug: 27465556 Change-Id: Ife0f43062e36ffc856f41683ddc4d91a7787333e
2016-04-12 17:22:06 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_METRIC_TESTS := $(TARGET_OUT_DATA)/benchmarktest
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
endif
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
Build cache.img on demand Bug: 5153694 To build cache.img, set BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE (required, ext4 only for now), BOARD_CACHEIMAGE_PARTITION_SIZE (optional) in BoardConfig.mk. Change-Id: I1d8b91646aa1dba88285e008ad3335768bcbddd2
2011-11-05 02:37:01 +08:00
TARGET_OUT_CACHE := $(PRODUCT_OUT)/cache
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_OUT_VENDOR := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_VENDOR)
Add support of SANITIZE_TARGET='address coverage' for fuzzing. Also, add trace-cmp instrumentation to fuzz_test and host_fuzz_test. Bug: 22850550 Change-Id: Ifff7b8be693ae991feb0a64e19439370a19b2748
2015-09-19 02:54:43 +08:00
ifneq ($(filter address,$(SANITIZE_TARGET)),)
Refactor sanitized library on-disk layout - Make. This CL moves the location of ASAN-ified libraries on disk in the following manner: /data/lib* --> /data/asan/system/lib* /data/vendor/* --> /data/asan/vendor/* There are a couple of advantages to this, including better isolation from other components, and more transparent linker renaming and SELinux policies. Bug: 36574794 Bug: 36674745 Test: m -j40 && SANITIZE_TARGET="address" m -j40 and the device boots. All sanitized libraries are correctly located in /data/asan/*. Change-Id: Ic6ba8e43e31df2ea92b85fd60f572823b6883ba2
2017-03-30 06:32:04 +08:00
target_out_vendor_shared_libraries_base := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_ASAN)/vendor
Move sanitized vendor libraries to /data/vendor/lib(|64). Sanitized RPATH now mentions /system/vendor/lib to preserve overlay in the case when a sanitized version of a vendor library can not be built. Bug: 22199458 Change-Id: I3222d2e1d6c08fdd1e0404fcb7db347aa4a92bb7
2015-07-01 05:02:02 +08:00
else
target_out_vendor_shared_libraries_base := $(TARGET_OUT_VENDOR)
endif
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_VENDOR_EXECUTABLES := $(TARGET_OUT_VENDOR)/bin
TARGET_OUT_VENDOR_OPTIONAL_EXECUTABLES := $(TARGET_OUT_VENDOR)/xbin
More consistent use of 64-bit build variable. Set up TARGET_IS_64_BIT and HOST_IS_64_BIT early so we don't need 2 mechanisms to judge if it's 64-bit build; Remove the unnecessary 32-bit host variables. Change-Id: I08d6d4d9ea70f91135fe2ee05463fb9a0d1cee42
2014-07-09 08:07:36 +08:00
ifeq ($(TARGET_IS_64_BIT),true)
Move sanitized vendor libraries to /data/vendor/lib(|64). Sanitized RPATH now mentions /system/vendor/lib to preserve overlay in the case when a sanitized version of a vendor library can not be built. Bug: 22199458 Change-Id: I3222d2e1d6c08fdd1e0404fcb7db347aa4a92bb7
2015-07-01 05:02:02 +08:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(target_out_vendor_shared_libraries_base)/lib64
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
else
Move sanitized vendor libraries to /data/vendor/lib(|64). Sanitized RPATH now mentions /system/vendor/lib to preserve overlay in the case when a sanitized version of a vendor library can not be built. Bug: 22199458 Change-Id: I3222d2e1d6c08fdd1e0404fcb7db347aa4a92bb7
2015-07-01 05:02:02 +08:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(target_out_vendor_shared_libraries_base)/lib
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
endif
Add TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE definition. - TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE is the output directory of RENDERSCRIPT_BITCODE (libclcore.bc) for vendors. - It is only used if LOCAL_PROPRIETARY_MODULE := true specified for the bitcode module. Bug: 34396220 Bug: 34334222 Test: mm Change-Id: I10237470eff0d8a693ce73313944e9b24595c5b7
2017-03-02 11:39:19 +08:00
TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE := $(TARGET_OUT_VENDOR_SHARED_LIBRARIES)
Install 64-bit libraries to /system/lib64. /system/lib always contains 32-bit libraries, and /system/lib64 (if present) always contains 64-bit libraries. Move things around a little bit, so TARGET_ARCH can be used to define the build paths. Bug: 11654773 Change-Id: I2edd91e162c7a20d7719d7bae15e5fa6c2a5b498
2014-01-14 08:14:20 +08:00
TARGET_OUT_VENDOR_JAVA_LIBRARIES := $(TARGET_OUT_VENDOR)/framework
TARGET_OUT_VENDOR_APPS := $(TARGET_OUT_VENDOR)/app
Define TARGET_OUT_VENDOR_APPS_PRIVILEGED When LOCAL_PROPRIETARY_MODULE is set to true when building an apk with, LOCAL_PRIVILEGED_MODULE set to true, the path is unknown. Add TARGET_OUT_VENDOR_APPS_PRIVILEGED to path definitions. Change-Id: Icbbafba96b7880f51ca3afcee53d5f3dd5b86a45 Signed-off-by: Benjamin Pujol <benjamin.pujol@intel.com> Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
2015-08-17 13:31:21 +08:00
TARGET_OUT_VENDOR_APPS_PRIVILEGED := $(TARGET_OUT_VENDOR)/priv-app
Install path support for vendor modules. Bug: 5284764 Set "LOCAL_PROPRIETARY_MODULE := true" to install module to vendor partition. Change-Id: I1301acc10664a12e313f3b868d9fd6400ac8b133
2011-09-14 04:57:26 +08:00
TARGET_OUT_VENDOR_ETC := $(TARGET_OUT_VENDOR)/etc
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_EXECUTABLES := $(TARGET_OUT_VENDOR_EXECUTABLES)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
Build: Fix vendor sanitizer library for secondary arch Fix the directory for secondary-architecture libraries under sanitization. These incorrectly wrote into vendor/lib instead of data/vendor/lib. Bug: 29498013 Change-Id: Iee08422a1f7ad42cbe71a322347e98cb74e3ef7f
2016-07-01 11:20:38 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(target_out_vendor_shared_libraries_base)/lib/$(TARGET_2ND_ARCH)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
else
Build: Fix vendor sanitizer library for secondary arch Fix the directory for secondary-architecture libraries under sanitization. These incorrectly wrote into vendor/lib instead of data/vendor/lib. Bug: 29498013 Change-Id: Iee08422a1f7ad42cbe71a322347e98cb74e3ef7f
2016-07-01 11:20:38 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(target_out_vendor_shared_libraries_base)/lib
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
endif
Add TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE definition. - TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE is the output directory of RENDERSCRIPT_BITCODE (libclcore.bc) for vendors. - It is only used if LOCAL_PROPRIETARY_MODULE := true specified for the bitcode module. Bug: 34396220 Bug: 34334222 Test: mm Change-Id: I10237470eff0d8a693ce73313944e9b24595c5b7
2017-03-02 11:39:19 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE := $($(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES)
Add 2nd arch directories for apps Apps built for 2nd arch install in the same directories as when built for the 1st arch. Change-Id: Ib1d950e186eef88212b44d04e6bc6c30a3d56155
2014-01-25 05:37:07 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS := $(TARGET_OUT_VENDOR_APPS)
Define TARGET_OUT_VENDOR_APPS_PRIVILEGED for 2nd arch Build error when LOCAL_PROPRIETARY_MODULE, LOCAL_PRIVILEGED_MODULE, and LOCAL_MULTILIB := 32 are set for a module in 64-bit build. The patch adds path definition for $(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS_PRIVILEGED Change-Id: I2fe0c0f28fb7e4a27defd3a1b04f84c8b296294f
2016-07-20 17:51:56 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS_PRIVILEGED := $(TARGET_OUT_VENDOR_APPS_PRIVILEGED)
Set up rules to build static libraries for TARGET_2ND_ARCH The rules for the 2nd arch are set up in the second inclusion of static_library_internal.mk. libfoo of the 2nd arch will be built into $(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a. Bug: 11654773 Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
2014-01-16 08:02:16 +08:00
Set up rules to build oem.img To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
2014-03-12 08:13:27 +08:00
TARGET_OUT_OEM := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_OEM)
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
TARGET_OUT_OEM_EXECUTABLES := $(TARGET_OUT_OEM)/bin
Support to configure and build multiple custom images. Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
2015-03-13 09:30:39 +08:00
ifeq ($(TARGET_IS_64_BIT),true)
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
TARGET_OUT_OEM_SHARED_LIBRARIES := $(TARGET_OUT_OEM)/lib64
else
TARGET_OUT_OEM_SHARED_LIBRARIES := $(TARGET_OUT_OEM)/lib
endif
Set up rules to build oem.img To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
2014-03-12 08:13:27 +08:00
# We don't expect Java libraries in the oem.img.
# TARGET_OUT_OEM_JAVA_LIBRARIES:= $(TARGET_OUT_OEM)/framework
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
TARGET_OUT_OEM_APPS := $(TARGET_OUT_OEM)/app
Set up rules to build oem.img To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
2014-03-12 08:13:27 +08:00
TARGET_OUT_OEM_ETC := $(TARGET_OUT_OEM)/etc
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_EXECUTABLES := $(TARGET_OUT_OEM_EXECUTABLES)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_SHARED_LIBRARIES := $(TARGET_OUT_OEM)/lib/$(TARGET_2ND_ARCH)
else
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_SHARED_LIBRARIES := $(TARGET_OUT_OEM)/lib
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
endif
Set up oem.img directory structure for TARGET_2ND_ARCH. Change-Id: Ia931a10708225c428b658cb4a30e8bba66fa7308
2014-06-27 05:12:35 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_APPS := $(TARGET_OUT_OEM_APPS)
Support to configure and build multiple custom images. Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
2015-03-13 09:30:39 +08:00
TARGET_OUT_ODM := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_ODM)
TARGET_OUT_ODM_EXECUTABLES := $(TARGET_OUT_ODM)/bin
ifeq ($(TARGET_IS_64_BIT),true)
TARGET_OUT_ODM_SHARED_LIBRARIES := $(TARGET_OUT_ODM)/lib64
else
TARGET_OUT_ODM_SHARED_LIBRARIES := $(TARGET_OUT_ODM)/lib
endif
TARGET_OUT_ODM_APPS := $(TARGET_OUT_ODM)/app
TARGET_OUT_ODM_ETC := $(TARGET_OUT_ODM)/etc
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_EXECUTABLES := $(TARGET_OUT_ODM_EXECUTABLES)
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
ifeq ($(TARGET_TRANSLATE_2ND_ARCH),true)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_SHARED_LIBRARIES := $(TARGET_OUT_ODM)/lib/$(TARGET_2ND_ARCH)
else
Support to configure and build multiple custom images. Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
2015-03-13 09:30:39 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_SHARED_LIBRARIES := $(TARGET_OUT_ODM)/lib
Support x86+arm multilib build. Support TARGET_2ND_ARCH as the binary translation arch. See target/board/generic_x86_arm/BoardConfig.mk and target/product/aosp_x86_arm.mk as example for the setup. In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the binary translation arch; Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's not a typical 64-bit multilib configuration. In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to install the TARGET_2ND_ARCH libraries. This also pulls in any dependency libraries. By default we don't install any TARGET_2ND_ARCH modules, unless it's pulled in by PRODUCT_PACKAGES. Bug: 27526885 Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009 (cherry-pick from commit 277e75a488b1b6599482aed9f7c046747baa10df)
2016-03-17 10:53:19 +08:00
endif
Support to configure and build multiple custom images. Build additional images requested by the product makefile. This script gives the ability to build multiple additional images and you can configure what modules/files to include in each image. 1. Define PRODUCT_CUSTOM_IMAGE_MAKEFILES in your product makefile. PRODUCT_CUSTOM_IMAGE_MAKEFILES is a list of makefiles. Each makefile configures an image. For image configuration makefile foo/bar/xyz.mk, the built image file name will be xyz.img. So make sure they won't conflict. 2. In each image's configuration makefile, you can define variables: - CUSTOM_IMAGE_MOUNT_POINT, the mount point, such as "oem", "odm" etc. - CUSTOM_IMAGE_PARTITION_SIZE - CUSTOM_IMAGE_FILE_SYSTEM_TYPE - CUSTOM_IMAGE_DICT_FILE, a text file defining a dictionary accepted by BuildImage() in tools/releasetools/build_image.py. - CUSTOM_IMAGE_MODULES, a list of module names you want to include in the image; Not only the module itself will be installed to proper path in the image, you can also piggyback additional files/directories with the module's LOCAL_PICKUP_FILES. - CUSTOM_IMAGE_COPY_FILES, a list of "<src>:<dest>" to be copied to the image. <dest> is relativ to the root of the image. To build all those images, run "make custom_images". Bug: 19609718 Change-Id: Ic73587e08503a251be27797c7b00329716051927 (cherry picked from commit 5fcf1094f9cf4d57c2598237f99621f254130d71)
2015-03-13 09:30:39 +08:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_APPS := $(TARGET_OUT_ODM_APPS)
Package breakpad symbols in target files zip When BREAKPAD_GENERATE_SYMBOLS is set to true, package the breakpad symbols into the target files zip thats generated with `make dist`. Bug: 24165970 Change-Id: I11c0d9a9d9e159475bfdb7bc338f9e9ac60aeada
2015-09-25 09:12:33 +08:00
TARGET_OUT_BREAKPAD := $(PRODUCT_OUT)/breakpad
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_OUT_UNSTRIPPED := $(PRODUCT_OUT)/symbols
TARGET_OUT_EXECUTABLES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/bin
TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/lib
build: fix vendor symbols in gdb Set TARGET_OUT_VENDOR_SHARED_LIBRARIES_UNSTRIPPED Append '64' for 64-bit libraries Change-Id: Ief289bb23950d4bed84cf616cff6038fbd8caf95
2014-06-21 04:33:36 +08:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/$(TARGET_COPY_OUT_VENDOR)/lib
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_ROOT_OUT_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)
TARGET_ROOT_OUT_SBIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/sbin
TARGET_ROOT_OUT_BIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/bin
Fix typo in coverage target out path. Change-Id: I4a448708ab74e08b2c515039ee5d71c32861214e
2016-09-16 08:32:13 +08:00
TARGET_OUT_COVERAGE := $(PRODUCT_OUT)/coverage
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_ROOT_OUT := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_ROOT)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_ROOT_OUT_BIN := $(TARGET_ROOT_OUT)/bin
TARGET_ROOT_OUT_SBIN := $(TARGET_ROOT_OUT)/sbin
TARGET_ROOT_OUT_ETC := $(TARGET_ROOT_OUT)/etc
TARGET_ROOT_OUT_USR := $(TARGET_ROOT_OUT)/usr
Add TARGET_COPY_OUT_* variables. They are relative to PRODUCT_OUT so can be used in PRODUCT_COPY_FILES. If TARGET_COPY_OUT_VENDOR instead of hardcoded system/vendor is used, we will be able to transition smoothly to a separate vendor staging directory. Change-Id: Ia9fdb208768cf4699180306280b4c02421b2ea9c
2011-10-28 06:18:39 +08:00
TARGET_RECOVERY_OUT := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_RECOVERY)
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
TARGET_RECOVERY_ROOT_OUT := $(TARGET_RECOVERY_OUT)/root
TARGET_SYSLOADER_OUT := $(PRODUCT_OUT)/sysloader
TARGET_SYSLOADER_ROOT_OUT := $(TARGET_SYSLOADER_OUT)/root
TARGET_SYSLOADER_SYSTEM_OUT := $(TARGET_SYSLOADER_OUT)/root/system
TARGET_INSTALLER_OUT := $(PRODUCT_OUT)/installer
TARGET_INSTALLER_DATA_OUT := $(TARGET_INSTALLER_OUT)/data
TARGET_INSTALLER_ROOT_OUT := $(TARGET_INSTALLER_OUT)/root
TARGET_INSTALLER_SYSTEM_OUT := $(TARGET_INSTALLER_OUT)/root/system
Move odex related files to product-specific dir. For target Java libraries, now the LOCAL_BUILT_MODULE includes both javalib.jar and the .odex file, if dexpreopt is enabled. These 2 files are moved to a product-specific dir in this change. For target Java Libraries, $(intermediates) now points to the product-specific dir. There is still a javalib.jar in the $(intermediates.COMMON) dir, which is used as dependency. Nothing is changed for host Java libraries. Change-Id: I2546dbb940c74537864ca002d1acb49bb731fbbc
2010-09-25 09:09:04 +08:00
COMMON_MODULE_CLASSES := TARGET-NOTICE_FILES HOST-NOTICE_FILES HOST-JAVA_LIBRARIES
Add Header Library support to Make We currently use static libraries without any source files to represent header libraries, but Soong actually has cc_library_headers. So to export those in a separate namespace from static libraries, implement them in Make as well. This also adds a nice pretty-warning / pretty-error macro that can be used to print out standard warning messages pointing to the real source file having the problem. Test: Use a header library exported by Soong in a Make module Change-Id: I3486539e247524cb82a20620745fc7be03014e14
2017-02-16 07:48:11 +08:00
PER_ARCH_MODULE_CLASSES := SHARED_LIBRARIES STATIC_LIBRARIES EXECUTABLES GYP RENDERSCRIPT_BITCODE NATIVE_TESTS HEADER_LIBRARIES
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
ifeq (,$(strip $(DIST_DIR)))
DIST_DIR := $(OUT_DIR)/dist
endif
Stop double-printing config Don't print the config in Kati when we've already printed it in soong_ui or the make wrapper. Test: m -j Test: USE_SOONG_UI=true m -j Change-Id: Ic6dce0ab29d584d85c6642c597f6e9dcd6ba9dca
2017-02-19 02:32:13 +08:00
ifndef KATI
PRINT_BUILD_CONFIG ?= true
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
endif
Set USE_CLANG_PLATFORM_BUILD to default true. BUG: 26102335 Change-Id: I3b9fa2dfbee361410caf163147945ab448bb8ddf
2016-01-20 03:43:44 +08:00
ifeq ($(USE_CLANG_PLATFORM_BUILD),)
USE_CLANG_PLATFORM_BUILD := true
endif
Error on USE_CLANG_PLATFORM_BUILD= A blank USE_CLANG_PLATFORM_BUILD= on the command line for make causes confusion between make and kati. make ignores writes to variables set on the command line, so envsetup.mk cannot set it to true, USE_CLANG_PLATFORM_BUILD is still empty in soong.mk, and soong.variables gets DeviceUsesClang: false. kati gets USE_CLANG_PLATFORM_BUILD= in its environment instead of on its command line, so envsetup.mk when parsed by kati sets USE_CLANG_PLATFORM_BUILD=true. Error out early if USE_CLANG_PLATFORM_BUILD is not true or false after attempting to set it to true if it is empty. Change-Id: I0e2731315711db9a6ac6ea2bf49c88bccacd35f7
2016-05-20 03:59:54 +08:00
ifneq ($(USE_CLANG_PLATFORM_BUILD),true)
ifneq ($(USE_CLANG_PLATFORM_BUILD),false)
$(error USE_CLANG_PLATFORM_BUILD must be true or false)
endif
endif