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

478 lines
19 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
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
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.
Switch the required host Java environment to 1.6. The path to the Java toolchain is now explicitly specified so no manual configuration should be required. Change-Id: I84abc122c557372e77e4579e9a9efe56af2b412c The java version changed, and we made envsetup automatically find the right JAVA_HOME. This change forces everyone to re-source envsetup.sh Change-Id: Ieb9512d5725cca26a83debf9b0480bc20e19d5ee Fix javadoc for Java 6. If you don't set bootclasspath, there would be errors like: javadoc: error - In doclet class DroidDoc, method start has thrown an exception java.lang.reflect.InvocationTargetException Change-Id: I1b83360cb595d50577c6043d6e91b0f92e4c04d6 Avoid inheriting PRIVATE_BOOTCLASSPATH from moduels that depend on api-stubs-timestamp The inherited value has caused build breakage on Mac build. Change-Id: I8a1b1d6c6d411f6aaaee2d8dbd0297e3d60ab5c2 Ignore STAY_OFF_MY_LAWN when setting JAVA_HOME. Don't check STAY_OFF_MY_LAWN in set_java_home. That function already refuses to update JAVA_HOME if it's set to something, which should be sufficient for anybody who doesn't want the script to mess with it. With this change, you can get the benefits of the 1.5/1.6 auto-selection without having to suffer through window title changes. Change-Id: I5cfc5d6fdf26a10b42b52925f877012c0506b9a5
2010-06-22 07:26:38 +08:00
CORRECT_BUILD_ENV_SEQUENCE_NUMBER := 10
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
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
ifneq (,$(findstring x86,$(UNAME)))
$(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
TARGET_COPY_OUT_DATA := data
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))
###########################################
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
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 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
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
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
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
HOST_OUT_INTERMEDIATES := $(HOST_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
HOST_OUT_HEADERS := $(HOST_OUT_INTERMEDIATES)/include
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
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
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_HEADERS := $(HOST_CROSS_OUT_INTERMEDIATES)/include
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)
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
ifeq ($(HOST_PREFER_32_BIT),true)
HOST_LIBRARY_PATH := $($(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_SHARED_LIBRARIES)
else
HOST_LIBRARY_PATH := $(HOST_OUT_SHARED_LIBRARIES)
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
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)
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)),)
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_base := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_DATA)
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
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Load compiler environment for a second arch. This is the first step to build 32-bit libraries in a 64-bit product. It will work like this: 1) In the product's BoardConfig.mk, define: TARGET_2ND_ARCH, TARGET_2ND_ARCH_VARIANT, TARGET_2ND_CPU_VARIANT. The build system uses those variables to set up an additional compiler environment for the second arch. 2) When parsing Android.mks, the build system sets up rules to build a module for both the 1st arch and the 2nd arch, unless it's explicitly asked to skip so. Android.mk will be adapted if there is additional rule of generating source files. The build system will accept arch-specific LOCAL_ variables, such as LOCAL_CFLAGS_arm, LOCAL_CFLAGS_armv7-a-neon, LOCAL_CFLAGS_cortex-a15, LOCAL_CFLAGS_aarch64 etc. Modules use such variables to set up build for various archs at the same time. 3) Install binary of the 2nd arch by adding "<module_name>:32" to PRODUCT_PACKAGES. All 2nd-arch libraries linked in by "<module_name>:32" will be installed automatically. Bug: 11654773 Change-Id: I2df63cd5463a07bf5358bee2a109f8fb9590fe30
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)
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
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
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)
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
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)),)
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_base := $(PRODUCT_OUT)/$(TARGET_COPY_OUT_DATA)/vendor
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
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)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(TARGET_OUT_VENDOR)/lib/$(TARGET_2ND_ARCH)
else
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
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $(TARGET_OUT_VENDOR)/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 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)
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
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
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
PER_ARCH_MODULE_CLASSES := SHARED_LIBRARIES STATIC_LIBRARIES EXECUTABLES GYP RENDERSCRIPT_BITCODE
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
ifeq (,$(strip $(DIST_DIR)))
DIST_DIR := $(OUT_DIR)/dist
endif
ifeq ($(PRINT_BUILD_CONFIG),)
PRINT_BUILD_CONFIG := true
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