2009-03-04 04:28:42 +01: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
2015-06-09 19:35:45 +02: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.
2009-03-04 04:28:42 +01:00
2017-03-28 22:07:56 +02:00
# Returns all words in $1 up to and including $2
d e f i n e f i n d _ a n d _ e a r l i e r
$( strip $( if $( 1) ,
$( firstword $( 1) )
$( if $( filter $( firstword $( 1) ) ,$( 2) ) ,,
$( call find_and_earlier,$( wordlist 2,$( words $( 1) ) ,$( 1) ) ,$( 2) ) ) ) )
e n d e f
#$(warning $(call find_and_earlier,A B C,A))
#$(warning $(call find_and_earlier,A B C,B))
#$(warning $(call find_and_earlier,A B C,C))
#$(warning $(call find_and_earlier,A B C,D))
d e f i n e v e r s i o n - l i s t
$( 1) P R 1 $( 1) P D 1 $( 1) P D 2 $( 1) P M 1 $( 1) P M 2
e n d e f
ALL_VERSIONS := O P Q R S T U V W X Y Z
ALL_VERSIONS := $( foreach v,$( ALL_VERSIONS) ,$( call version-list,$( v) ) )
# Filters ALL_VERSIONS down to the range [$1, $2], and errors if $1 > $2 or $3 is
# not in [$1, $2]
# $(1): min platform version
# $(2): max platform version
# $(3): default platform version
d e f i n e a l l o w e d - p l a t f o r m - v e r s i o n s
$( strip \
$( if $( filter $( ALL_VERSIONS) ,$( 1) ) ,,
$( error Invalid MIN_PLATFORM_VERSION '$(1)' ) )
$( if $( filter $( ALL_VERSIONS) ,$( 2) ) ,,
$( error Invalid MAX_PLATFORM_VERSION '$(2)' ) )
$( if $( filter $( ALL_VERSIONS) ,$( 3) ) ,,
$( error Invalid DEFAULT_PLATFORM_VERSION '$(3)' ) )
$( eval allowed_versions_ := $( call find_and_earlier,$( ALL_VERSIONS) ,$( 2) ) )
$( if $( filter $( allowed_versions_) ,$( 1) ) ,,
$( error MIN_PLATFORM_VERSION '$(1)' must be before MAX_PLATFORM_VERSION '$(2)' ) )
$( eval allowed_versions_ := $( 1) \
$( filter-out $( call find_and_earlier,$( allowed_versions_) ,$( 1) ) ,$( allowed_versions_) ) )
$( if $( filter $( allowed_versions_) ,$( 3) ) ,,
$( error DEFAULT_PLATFORM_VERSION '$(3)' must be between MIN_PLATFORM_VERSION '$(1)' and MAX_PLATFORM_VERSION '$(2)' ) )
$( allowed_versions_) )
e n d e f
#$(warning $(call allowed-platform-versions,OPR1,PPR1,OPR1))
#$(warning $(call allowed-platform-versions,OPM1,PPR1,OPR1))
2009-05-13 06:45:23 +02:00
# Set up version information.
i n c l u d e $( BUILD_SYSTEM ) / v e r s i o n _ d e f a u l t s . m k
2017-03-28 22:07:56 +02:00
ENABLED_VERSIONS := $( call find_and_earlier,$( ALL_VERSIONS) ,$( TARGET_PLATFORM_VERSION) )
$( foreach v ,$ ( ENABLED_VERSIONS ) , \
$( eval IS_AT_LEAST_$( v) := true ) )
2009-03-04 04:28:42 +01: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.
2017-03-22 01:41:03 +01:00
CORRECT_BUILD_ENV_SEQUENCE_NUMBER := 13
2009-03-04 04:28:42 +01:00
# ---------------------------------------------------------------
2011-07-12 07:11:46 +02:00
# The product defaults to generic on hardware
2009-03-04 04:28:42 +01:00
# NOTE: This will be overridden in product_config.mk if make
# was invoked with a PRODUCT-xxx-yyy goal.
i f e q ( $( TARGET_PRODUCT ) , )
2015-06-08 20:57:26 +02:00
TARGET_PRODUCT := aosp_arm
2009-03-04 04:28:42 +01:00
e n d i f
# the variant -- the set of files that are included for a build
i f e q ( $( strip $ ( TARGET_BUILD_VARIANT ) ) , )
TARGET_BUILD_VARIANT := eng
e n d i f
# ---------------------------------------------------------------
# Set up configuration for host machine. We don't do cross-
2012-07-26 04:57:22 +02:00
# compiles except for arm/mips, so the HOST is whatever we are
2009-03-04 04:28:42 +01:00
# running on
# HOST_OS
i f n e q ( , $( findstring Linux ,$ ( UNAME ) ) )
2014-04-17 19:03:35 +02:00
HOST_OS := linux
2009-03-04 04:28:42 +01:00
e n d i f
i f n e q ( , $( findstring Darwin ,$ ( UNAME ) ) )
2014-04-17 19:03:35 +02:00
HOST_OS := darwin
2009-03-04 04:28:42 +01:00
e n d i f
i f n e q ( , $( findstring Macintosh ,$ ( UNAME ) ) )
2014-04-17 19:03:35 +02:00
HOST_OS := darwin
2009-03-04 04:28:42 +01:00
e n d i f
2010-04-17 02:50:09 +02:00
2017-07-25 09:57:38 +02:00
HOST_OS_EXTRA := $( shell uname -rsm)
i f e q ( $( HOST_OS ) , l i n u x )
ifneq ( $( wildcard /etc/os-release) ,)
HOST_OS_EXTRA += $( shell source /etc/os-release; echo $$ PRETTY_NAME)
endif
e l s e i f e q ( $( HOST_OS ) , d a r w i n )
HOST_OS_EXTRA += $( shell sw_vers -productVersion)
e n d i f
HOST_OS_EXTRA := $( subst $( space) ,-,$( HOST_OS_EXTRA) )
2016-03-04 05:57:21 +01:00
2010-04-17 02:50:09 +02:00
# BUILD_OS is the real host doing the build.
BUILD_OS := $( HOST_OS)
2015-08-14 21:59:50 +02:00
HOST_CROSS_OS :=
# We can cross-build Windows binaries on Linux
2010-04-17 02:50:09 +02:00
i f e q ( $( HOST_OS ) , l i n u x )
2017-11-06 20:03:28 +01:00
i f e q ( $( BUILD_HOST_static ) , )
2015-08-14 21:59:50 +02:00
HOST_CROSS_OS := windows
HOST_CROSS_ARCH := x86
2016-02-06 01:20:19 +01:00
HOST_CROSS_2ND_ARCH := x86_64
2016-05-17 07:07:31 +02:00
2ND_HOST_CROSS_IS_64_BIT := true
2010-04-17 02:50:09 +02:00
e n d i f
2017-11-06 20:03:28 +01:00
e n d i f
2009-03-04 04:28:42 +01:00
i f e q ( $( HOST_OS ) , )
$(error Unable to determine HOST_OS from uname -sm : $( UNAME ) !)
e n d i f
# HOST_ARCH
2014-04-17 19:03:35 +02:00
i f n e q ( , $( findstring x 86_ 64,$ ( UNAME ) ) )
2014-06-09 21:31:12 +02:00
HOST_ARCH := x86_64
HOST_2ND_ARCH := x86
2014-07-09 02:07:36 +02:00
HOST_IS_64_BIT := true
2015-03-20 19:39:00 +01:00
e l s e
2016-06-29 21:26:53 +02:00
i f n e q ( , $( findstring i 686,$ ( UNAME ) ) $( findstring x 86,$ ( UNAME ) ) )
2015-03-20 19:39:00 +01:00
$(error Building on a 32-bit x86 host is not supported : $( UNAME ) !)
e n d i f
2009-03-04 04:28:42 +01:00
e n d i f
2018-08-28 10:51:25 +02:00
i f e q ( $( HOST_OS ) , d a r w i n )
# Mac no longer supports 32-bit executables
HOST_2ND_ARCH :=
e n d i f
2010-04-17 02:50:09 +02:00
BUILD_ARCH := $( HOST_ARCH)
2014-04-17 19:03:35 +02:00
BUILD_2ND_ARCH := $( HOST_2ND_ARCH)
2010-04-17 02:50:09 +02:00
2009-03-04 04:28:42 +01:00
i f e q ( $( HOST_ARCH ) , )
$(error Unable to determine HOST_ARCH from uname -sm : $( UNAME ) !)
e n d i f
# the host build defaults to release, and it must be release or debug
i f e q ( $( HOST_BUILD_TYPE ) , )
HOST_BUILD_TYPE := release
e n d i f
i f n e q ( $( HOST_BUILD_TYPE ) , r e l e a s e )
i f n e q ( $( HOST_BUILD_TYPE ) , d e b u g )
$( error HOST_BUILD_TYPE must be either release or debug , not '$ ( HOST_BUILD_TYPE ) ')
e n d i f
e n d i f
2014-04-17 19:03:35 +02:00
# We don't want to move all the prebuilt host tools to a $(HOST_OS)-x86_64 dir.
HOST_PREBUILT_ARCH := x86
2009-03-04 04:28:42 +01:00
# This is the standard way to name a directory containing prebuilt host
# objects. E.g., prebuilt/$(HOST_PREBUILT_TAG)/cc
2015-05-04 21:44:44 +02:00
HOST_PREBUILT_TAG := $( BUILD_OS) -$( HOST_PREBUILT_ARCH)
2009-03-04 04:28:42 +01:00
2011-10-28 00:18:39 +02: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
2016-06-16 23:47:10 +02:00
TARGET_COPY_OUT_SYSTEM_OTHER := system_other
2011-10-28 00:18:39 +02:00
TARGET_COPY_OUT_DATA := data
2017-03-30 00:32:04 +02:00
TARGET_COPY_OUT_ASAN := $( TARGET_COPY_OUT_DATA) /asan
2014-03-12 01:13:27 +01:00
TARGET_COPY_OUT_OEM := oem
2018-08-09 23:26:00 +02:00
TARGET_COPY_OUT_RAMDISK := ramdisk
2011-10-28 00:18:39 +02:00
TARGET_COPY_OUT_ROOT := root
TARGET_COPY_OUT_RECOVERY := recovery
2018-10-02 15:10:16 +02:00
# The directory used for optional partitions depend on the BoardConfig, so
# they're defined to placeholder values here and swapped after reading the
# BoardConfig, to be either the partition dir, or a subdir within 'system'.
2014-07-24 05:20:49 +02:00
_vendor_path_placeholder := || VENDOR-PATH-PH||
2017-11-27 09:04:47 +01:00
_product_path_placeholder := || PRODUCT-PATH-PH||
2018-08-17 23:01:25 +02:00
_product_services_path_placeholder := || PRODUCT_SERVICES-PATH-PH||
2017-11-14 16:42:30 +01:00
_odm_path_placeholder := || ODM-PATH-PH||
2018-10-02 15:10:16 +02:00
TARGET_COPY_OUT_VENDOR := $( _vendor_path_placeholder)
TARGET_COPY_OUT_PRODUCT := $( _product_path_placeholder)
TARGET_COPY_OUT_PRODUCT_SERVICES := $( _product_services_path_placeholder)
2017-11-14 16:42:30 +01:00
TARGET_COPY_OUT_ODM := $( _odm_path_placeholder)
2018-10-02 15:10:16 +02:00
# Returns the non-sanitized version of the path provided in $1.
d e f i n e g e t _ n o n _ a s a n _ p a t h
$( patsubst $ ( PRODUCT_OUT ) /$ ( TARGET_COPY_OUT_ASAN ) /%,$ ( PRODUCT_OUT ) /%,$ 1)
e n d e f
2017-11-14 16:42:30 +01:00
2017-06-15 19:41:02 +02:00
#################################################################
# Set up minimal BOOTCLASSPATH list of jars to build/execute
# java code with dalvikvm/art.
2018-11-09 16:57:35 +01:00
TARGET_CORE_JARS := core-oj core-libart conscrypt okhttp bouncycastle apache-xml
2017-09-14 23:58:02 +02:00
i f e q ( $( EMMA_INSTRUMENT ) , t r u e )
ifneq ( $( EMMA_INSTRUMENT_STATIC) ,true)
# For instrumented build, if Jacoco is not being included statically
# in instrumented packages then include Jacoco classes into the
# bootclasspath.
TARGET_CORE_JARS += jacocoagent
endif # EMMA_INSTRUMENT_STATIC
e n d i f # EMMA_INSTRUMENT
2017-06-15 19:41:02 +02:00
HOST_CORE_JARS := $( addsuffix -hostdex,$( TARGET_CORE_JARS) )
#################################################################
2014-07-24 05:20:49 +02:00
# Read the product specs so we can get TARGET_DEVICE and other
2011-06-17 01:58:11 +02:00
# variables that we need in order to locate the output files.
i n c l u d e $( BUILD_SYSTEM ) / p r o d u c t _ c o n f i g . m k
2010-09-22 19:59:10 +02:00
2011-11-17 23:51:12 +01:00
build_variant := $( filter-out eng user userdebug,$( TARGET_BUILD_VARIANT) )
2011-06-17 01:58:11 +02:00
i f n e q ( $( build_variant ) - $( words $ ( TARGET_BUILD_VARIANT ) ) , - 1 )
$(warning bad TARGET_BUILD_VARIANT : $( TARGET_BUILD_VARIANT ) )
2011-11-17 23:51:12 +01:00
$(error must be empty or one of : eng user userdebug )
2011-06-17 01:58:11 +02:00
e n d i f
2009-03-04 04:28:42 +01:00
2014-09-03 00:11:20 +02:00
SDK_HOST_ARCH := x86
2014-01-14 01:14:20 +01: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.
2018-05-02 09:15:41 +02:00
i f d e f T A R G E T _ D E V I C E _ D I R
ifneq ( $( origin TARGET_DEVICE_DIR) ,command line)
$( error TARGET_DEVICE_DIR may not be set manually)
endif
board_config_mk := $( TARGET_DEVICE_DIR) /BoardConfig.mk
e l s e
board_config_mk := \
$( strip $( sort $( wildcard \
$( SRC_TARGET_DIR) /board/$( TARGET_DEVICE) /BoardConfig.mk \
$( 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' ) \
) ) )
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
TARGET_DEVICE_DIR := $( patsubst %/,%,$( dir $( board_config_mk) ) )
.KATI_READONLY := TARGET_DEVICE_DIR
2014-01-14 01:14:20 +01:00
e n d i f
i n c l u d e $( board_config_mk )
i f e q ( $( TARGET_ARCH ) , )
$( error TARGET_ARCH not defined by board config: $( board_config_mk) )
e n d i f
2016-01-22 20:24:59 +01:00
i f n e q ( $( 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)
e n d i f
2014-01-14 01:14:20 +01:00
board_config_mk :=
2018-06-21 18:46:01 +02:00
###########################################
# Handle BUILD_BROKEN_* settings
vars := \
BUILD_BROKEN_ANDROIDMK_EXPORTS \
BUILD_BROKEN_DUP_COPY_HEADERS \
BUILD_BROKEN_DUP_RULES \
BUILD_BROKEN_PHONY_TARGETS
$(foreach var,$(vars),$(eval $(var) : = $$( strip $ $ ( $ ( var ) ) ) ))
$( foreach var ,$ ( vars ) , \
$( if $( filter-out true false,$( $( var) ) ) , \
$( error Valid values of $( var) are "true" , "false" , and "" . Not " $( $( var) ) " ) ) )
.KATI_READONLY := $( vars)
2018-02-27 11:15:32 +01:00
CHANGES_URL := https://android.googlesource.com/platform/build/+/master/Changes.md
2018-07-24 07:19:40 +02:00
i f n e q ( $( BUILD_BROKEN_ANDROIDMK_EXPORTS ) , t r u e )
2018-02-27 11:15:32 +01:00
$( KATI_obsolete_export It is a global setting . See $ ( CHANGES_URL ) #export_keyword )
e n d i f
CHANGES_URL :=
2018-06-21 18:46:01 +02:00
2018-08-09 23:26:00 +02:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_RAMDISK
i f e q ( $( BOARD_BUILD_SYSTEM_ROOT_IMAGE ) , t r u e )
TARGET_COPY_OUT_RAMDISK := $( TARGET_COPY_OUT_ROOT)
e n d i f
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
###########################################
# Configure whether we're building the system image
BUILDING_SYSTEM_IMAGE := true
i f e q ( $( PRODUCT_BUILD_SYSTEM_IMAGE ) , )
ifndef PRODUCT_USE_DYNAMIC_PARTITION_SIZE
ifndef BOARD_SYSTEMIMAGE_PARTITION_SIZE
BUILDING_SYSTEM_IMAGE :=
endif
endif
e l s e i f e q ( $( PRODUCT_BUILD_SYSTEM_IMAGE ) , f a l s e )
BUILDING_SYSTEM_IMAGE :=
e n d i f
.KATI_READONLY := BUILDING_SYSTEM_IMAGE
# Are we building a system_other image
BUILDING_SYSTEM_OTHER_IMAGE :=
i f e q ( $( PRODUCT_BUILD_SYSTEM_OTHER_IMAGE ) , )
ifdef BUILDING_SYSTEM_IMAGE
ifeq ( $( BOARD_USES_SYSTEM_OTHER_ODEX) ,true)
BUILDING_SYSTEM_OTHER_IMAGE := true
endif
endif
e l s e i f e q ( $( PRODUCT_BUILD_SYSTEM_OTHER_IMAGE ) , t r u e )
BUILDING_SYSTEM_OTHER_IMAGE := true
ifndef BUILDING_SYSTEM_IMAGE
$( error PRODUCT_BUILD_SYSTEM_OTHER_IMAGE = true requires building the system image)
endif
e n d i f
.KATI_READONLY := BUILDING_SYSTEM_OTHER_IMAGE
# Are we building a cache image
BUILDING_CACHE_IMAGE :=
i f e q ( $( PRODUCT_BUILD_CACHE_IMAGE ) , )
ifdef BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
BUILDING_CACHE_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_CACHE_IMAGE ) , t r u e )
BUILDING_CACHE_IMAGE := true
ifndef BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
$( error PRODUCT_BUILD_CACHE_IMAGE set to true, but BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE not defined)
endif
e n d i f
.KATI_READONLY := BUILDING_CACHE_IMAGE
# TODO: Add BUILDING_BOOT_IMAGE / BUILDING_RECOVERY_IMAGE
# This gets complicated with BOARD_USES_RECOVERY_AS_BOOT, so skipping for now.
# Are we building a ramdisk image
BUILDING_RAMDISK_IMAGE := true
i f e q ( $( PRODUCT_BUILD_RAMDISK_IMAGE ) , )
# TODO: Be smarter about this. This probably only needs to happen when one of the follow is true:
# BUILDING_BOOT_IMAGE
# BUILDING_RECOVERY_IMAGE
e l s e i f e q ( $( PRODUCT_BUILD_RAMDISK_IMAGE ) , f a l s e )
BUILDING_RAMDISK_IMAGE :=
e n d i f
.KATI_READONLY := BUILDING_RAMDISK_IMAGE
# Are we building a userdata image
BUILDING_USERDATA_IMAGE :=
i f e q ( $( PRODUCT_BUILD_USERDATA_IMAGE ) , )
ifdef BOARD_USERDATAIMAGE_PARTITION_SIZE
BUILDING_USERDATA_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_USERDATA_IMAGE ) , t r u e )
BUILDING_USERDATA_IMAGE := true
e n d i f
.KATI_READONLY := BUILDING_USERDATA_IMAGE
2014-07-24 05:20:49 +02:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_VENDOR
i f e q ( $( TARGET_COPY_OUT_VENDOR ) , $( _vendor_path_placeholder ) )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
TARGET_COPY_OUT_VENDOR := system/vendor
2014-07-24 05:20:49 +02:00
e l s e i f e q ( $( filter vendor system /vendor ,$ ( TARGET_COPY_OUT_VENDOR ) ) , )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_VENDOR must be either 'vendor' or 'system/vendor' , seeing '$(TARGET_COPY_OUT_VENDOR)' .)
2014-07-24 05:20:49 +02:00
e n d i f
PRODUCT_COPY_FILES := $( subst $( _vendor_path_placeholder) ,$( TARGET_COPY_OUT_VENDOR) ,$( PRODUCT_COPY_FILES) )
2016-06-17 23:07:37 +02:00
BOARD_USES_VENDORIMAGE :=
i f d e f B O A R D _ P R E B U I L T _ V E N D O R I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_VENDORIMAGE := true
2016-06-17 23:07:37 +02:00
e n d i f
i f d e f B O A R D _ V E N D O R I M A G E _ F I L E _ S Y S T E M _ T Y P E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_VENDORIMAGE := true
2016-06-17 23:07:37 +02:00
e n d i f
i f e q ( $( TARGET_COPY_OUT_VENDOR ) , v e n d o r )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_VENDORIMAGE := true
2016-06-17 23:07:37 +02:00
e l s e i f d e f B O A R D _ U S E S _ V E N D O R I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_VENDOR must be set to 'vendor' to use a vendor image)
e n d i f
.KATI_READONLY := BOARD_USES_VENDORIMAGE
BUILDING_VENDOR_IMAGE :=
i f e q ( $( PRODUCT_BUILD_VENDOR_IMAGE ) , )
ifdef BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE
BUILDING_VENDOR_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_VENDOR_IMAGE ) , t r u e )
BUILDING_VENDOR_IMAGE := true
ifndef BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE
$( error PRODUCT_BUILD_VENDOR_IMAGE set to true, but BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE not defined)
endif
2016-06-17 23:07:37 +02:00
e n d i f
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
i f d e f B O A R D _ P R E B U I L T _ V E N D O R I M A G E
BUILDING_VENDOR_IMAGE :=
e n d i f
.KATI_READONLY := BUILDING_VENDOR_IMAGE
2017-11-27 09:04:47 +01:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_PRODUCT
i f e q ( $( TARGET_COPY_OUT_PRODUCT ) , $( _product_path_placeholder ) )
TARGET_COPY_OUT_PRODUCT := system/product
e l s e i f e q ( $( filter product system /product ,$ ( TARGET_COPY_OUT_PRODUCT ) ) , )
$( error TARGET_COPY_OUT_PRODUCT must be either 'product ' or 'system /product ', seeing '$ ( TARGET_COPY_OUT_PRODUCT ) '.)
e n d i f
PRODUCT_COPY_FILES := $( subst $( _product_path_placeholder) ,$( TARGET_COPY_OUT_PRODUCT) ,$( PRODUCT_COPY_FILES) )
BOARD_USES_PRODUCTIMAGE :=
i f d e f B O A R D _ P R E B U I L T _ P R O D U C T I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCTIMAGE := true
2017-11-27 09:04:47 +01:00
e n d i f
i f d e f B O A R D _ P R O D U C T I M A G E _ F I L E _ S Y S T E M _ T Y P E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCTIMAGE := true
2017-11-27 09:04:47 +01:00
e n d i f
i f e q ( $( TARGET_COPY_OUT_PRODUCT ) , p r o d u c t )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCTIMAGE := true
2017-11-27 09:04:47 +01:00
e l s e i f d e f B O A R D _ U S E S _ P R O D U C T I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_PRODUCT must be set to 'product' to use a product image)
e n d i f
.KATI_READONLY := BOARD_USES_PRODUCTIMAGE
BUILDING_PRODUCT_IMAGE :=
i f e q ( $( PRODUCT_BUILD_PRODUCT_IMAGE ) , )
ifdef BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
BUILDING_PRODUCT_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_PRODUCT_IMAGE ) , t r u e )
BUILDING_PRODUCT_IMAGE := true
ifndef BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
$( error PRODUCT_BUILD_PRODUCT_IMAGE set to true, but BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE not defined)
endif
e n d i f
i f d e f B O A R D _ P R E B U I L T _ P R O D U C T I M A G E
BUILDING_PRODUCT_IMAGE :=
2017-11-27 09:04:47 +01:00
e n d i f
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
.KATI_READONLY := BUILDING_PRODUCT_IMAGE
2017-11-27 09:04:47 +01:00
2018-05-29 14:09:01 +02:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_PRODUCT_SERVICES
2018-07-27 01:02:52 +02:00
i f e q ( $( TARGET_COPY_OUT_PRODUCT_SERVICES ) , $( _product_services_path_placeholder ) )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
TARGET_COPY_OUT_PRODUCT_SERVICES := system/product_services
2018-08-17 01:56:14 +02:00
e l s e i f e q ( $( filter product_services system /product_services ,$ ( TARGET_COPY_OUT_PRODUCT_SERVICES ) ) , )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_PRODUCT_SERVICES must be either 'product_services' or 'system/product_services' , seeing '$(TARGET_COPY_OUT_PRODUCT_SERVICES)' .)
2018-05-29 14:09:01 +02:00
e n d i f
2018-08-23 09:54:34 +02:00
PRODUCT_COPY_FILES := $( subst $( _product_services_path_placeholder) ,$( TARGET_COPY_OUT_PRODUCT_SERVICES) ,$( PRODUCT_COPY_FILES) )
2018-05-29 14:09:01 +02:00
BOARD_USES_PRODUCT_SERVICESIMAGE :=
i f d e f B O A R D _ P R E B U I L T _ P R O D U C T _ S E R V I C E S I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCT_SERVICESIMAGE := true
2018-05-29 14:09:01 +02:00
e n d i f
i f d e f B O A R D _ P R O D U C T _ S E R V I C E S I M A G E _ F I L E _ S Y S T E M _ T Y P E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCT_SERVICESIMAGE := true
2018-05-29 14:09:01 +02:00
e n d i f
2018-08-17 01:56:14 +02:00
i f e q ( $( TARGET_COPY_OUT_PRODUCT_SERVICES ) , p r o d u c t _ s e r v i c e s )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_PRODUCT_SERVICESIMAGE := true
2018-05-29 14:09:01 +02:00
e l s e i f d e f B O A R D _ U S E S _ P R O D U C T _ S E R V I C E S I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_PRODUCT_SERVICES must be set to 'product_services' to use a product_services image)
e n d i f
BUILDING_PRODUCT_SERVICES_IMAGE :=
2019-01-25 11:15:22 +01:00
i f e q ( $( PRODUCT_BUILD_PRODUCT_SERVICES_IMAGE ) , )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
ifdef BOARD_PRODUCT_SERVICESIMAGE_FILE_SYSTEM_TYPE
BUILDING_PRODUCT_SERVICES_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_PRODUCT_SERVICES_IMAGE ) , t r u e )
BUILDING_PRODUCT_SERVICES_IMAGE := true
ifndef BOARD_PRODUCT_SERVICESIMAGE_FILE_SYSTEM_TYPE
$( error PRODUCT_BUILD_PRODUCT_SERVICES_IMAGE set to true, but BOARD_PRODUCT_SERVICESIMAGE_FILE_SYSTEM_TYPE not defined)
endif
2018-05-29 14:09:01 +02:00
e n d i f
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
i f d e f B O A R D _ P R E B U I L T _ P R O D U C T _ S E R V I C E S I M A G E
BUILDING_PRODUCT_SERVICES_IMAGE :=
e n d i f
.KATI_READONLY := BUILDING_PRODUCT_SERVICES_IMAGE
2018-05-29 14:09:01 +02:00
2017-11-14 16:42:30 +01:00
###########################################
# Now we can substitute with the real value of TARGET_COPY_OUT_ODM
i f e q ( $( TARGET_COPY_OUT_ODM ) , $( _odm_path_placeholder ) )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
TARGET_COPY_OUT_ODM := vendor/odm
2017-11-14 16:42:30 +01:00
e l s e i f e q ( $( filter odm vendor /odm ,$ ( TARGET_COPY_OUT_ODM ) ) , )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_ODM must be either 'odm' or 'vendor/odm' , seeing '$(TARGET_COPY_OUT_ODM)' .)
2017-11-14 16:42:30 +01:00
e n d i f
PRODUCT_COPY_FILES := $( subst $( _odm_path_placeholder) ,$( TARGET_COPY_OUT_ODM) ,$( PRODUCT_COPY_FILES) )
BOARD_USES_ODMIMAGE :=
i f d e f B O A R D _ P R E B U I L T _ O D M I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_ODMIMAGE := true
2017-11-14 16:42:30 +01:00
e n d i f
i f d e f B O A R D _ O D M I M A G E _ F I L E _ S Y S T E M _ T Y P E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_ODMIMAGE := true
2017-11-14 16:42:30 +01:00
e n d i f
i f e q ( $( TARGET_COPY_OUT_ODM ) , o d m )
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
BOARD_USES_ODMIMAGE := true
2017-11-14 16:42:30 +01:00
e l s e i f d e f B O A R D _ U S E S _ O D M I M A G E
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
$( error TARGET_COPY_OUT_ODM must be set to 'odm' to use an odm image)
e n d i f
BUILDING_ODM_IMAGE :=
i f e q ( $( ODM_BUILD_ODM_IMAGE ) , )
ifdef BOARD_ODMIMAGE_FILE_SYSTEM_TYPE
BUILDING_ODM_IMAGE := true
endif
e l s e i f e q ( $( PRODUCT_BUILD_ODM_IMAGE ) , t r u e )
BUILDING_ODM_IMAGE := true
ifndef BOARD_ODMIMAGE_FILE_SYSTEM_TYPE
$( error PRODUCT_BUILD_ODM_IMAGE set to true, but BOARD_ODMIMAGE_FILE_SYSTEM_TYPE not defined)
endif
e n d i f
i f d e f B O A R D _ P R E B U I L T _ O D M I M A G E
BUILDING_ODM_IMAGE :=
2017-11-14 16:42:30 +01:00
e n d i f
Add PRODUCT_BUILD_*_IMAGE, BUILDING_*_IMAGE to control building of images
These centralize the decisions on whether to build certain images or
not, and allow the product definition to override that choice.
There are a few use cases here:
* For GSI-like cases, we only want to build the system image. This
didn't really change, but it's somewhat simpler to configure, and
easier to understand the build logic.
* On the opposite side, when you're planning on using a GSI, the device
specific build can only build the vendor images (or some other set).
* Some cases (Fuchsia, etc) don't want to build any images, as they'll
be distributing the build artifacts in their own packaging.
I suspect in the future, TARGET_BUILD_APPS may be able to be refactored
into the third use case.
Test: treehugger
Test: Create a product definition that includes nothing, try to build it.
Test: compare build-aosp_crosshatch.ninja and build-crosshatch.ninja before/after
Change-Id: I685ab841be3718d3dd7052c28ccd764bb6f1991a
2019-01-16 21:42:05 +01:00
.KATI_READONLY := BUILDING_ODM_IMAGE
2017-11-14 16:42:30 +01:00
2014-07-24 05:20:49 +02:00
###########################################
2017-01-05 02:16:09 +01:00
# Ensure that only TARGET_RECOVERY_UPDATER_LIBS *or* AB_OTA_UPDATER is set.
TARGET_RECOVERY_UPDATER_LIBS ?=
AB_OTA_UPDATER ?=
.KATI_READONLY := TARGET_RECOVERY_UPDATER_LIBS AB_OTA_UPDATER
i f e q ( $( AB_OTA_UPDATER ) , t r u e )
ifneq ( $( strip $( TARGET_RECOVERY_UPDATER_LIBS) ) ,)
$( error Do not use TARGET_RECOVERY_UPDATER_LIBS when using AB_OTA_UPDATER)
endif
e n d i f
2014-07-24 05:20:49 +02:00
2017-03-19 21:22:45 +01:00
# Check BOARD_VNDK_VERSION
2017-11-17 08:09:17 +01:00
d e f i n e c h e c k _ v n d k _ v e r s i o n
$( eval vndk_path := prebuilts/vndk/v$( 1) ) \
2017-12-29 07:21:14 +01:00
$( if $( wildcard $( vndk_path) /*/Android.bp) ,,$( error VNDK version $( 1) not found) )
2017-11-17 08:09:17 +01:00
e n d e f
2017-03-19 21:22:45 +01:00
i f d e f B O A R D _ V N D K _ V E R S I O N
ifneq ( $( BOARD_VNDK_VERSION) ,current)
2017-12-07 09:08:19 +01:00
$( error BOARD_VNDK_VERSION: Only "current" is implemented)
2017-03-19 21:22:45 +01:00
endif
2017-07-11 23:59:30 +02:00
TARGET_VENDOR_TEST_SUFFIX := /vendor
e l s e
TARGET_VENDOR_TEST_SUFFIX :=
2017-03-19 21:22:45 +01:00
e n d i f
2018-09-19 10:52:58 +02:00
i f e q ( , $( TARGET_BUILD_APPS ) )
2017-11-17 08:09:17 +01:00
i f d e f P R O D U C T _ E X T R A _ V N D K _ V E R S I O N S
$( foreach v,$( PRODUCT_EXTRA_VNDK_VERSIONS) ,$( call check_vndk_version,$( v) ) )
e n d i f
2018-09-19 10:52:58 +02:00
e n d i f
2017-11-17 08:09:17 +01:00
2018-01-15 06:48:40 +01:00
# Ensure that BOARD_SYSTEMSDK_VERSIONS are all within PLATFORM_SYSTEMSDK_VERSIONS
_unsupported_systemsdk_versions := $( filter-out $( PLATFORM_SYSTEMSDK_VERSIONS) ,$( BOARD_SYSTEMSDK_VERSIONS) )
i f n e q ( , $( _unsupported_systemsdk_versions ) )
$( error System SDK versions '$(_unsupported_systemsdk_versions)' in BOARD_SYSTEMSDK_VERSIONS are not supported.\
Supported versions are $( PLATFORM_SYSTEMSDK_VERSIONS) )
e n d i f
2009-03-04 04:28:42 +01:00
# ---------------------------------------------------------------
# Set up configuration for target machine.
# The following must be set:
# TARGET_OS = { linux }
2012-07-26 04:57:22 +02:00
# TARGET_ARCH = { arm | x86 | mips }
2009-03-04 04:28:42 +01:00
TARGET_OS := linux
2012-07-26 04:57:22 +02:00
# TARGET_ARCH should be set by BoardConfig.mk and will be checked later
2014-07-09 02:07:36 +02:00
i f n e q ( $( filter %64,$ ( TARGET_ARCH ) ) , )
TARGET_IS_64_BIT := true
e n d i f
2009-03-04 04:28:42 +01:00
# the target build type defaults to release
i f n e q ( $( TARGET_BUILD_TYPE ) , d e b u g )
TARGET_BUILD_TYPE := release
e n d i f
# ---------------------------------------------------------------
# figure out the output directories
2016-05-28 00:15:47 +02:00
SOONG_OUT_DIR := $( OUT_DIR) /soong
2017-09-08 23:29:51 +02:00
TARGET_OUT_ROOT := $( OUT_DIR) /target
2009-03-04 04:28:42 +01:00
2017-09-08 23:29:51 +02:00
HOST_OUT_ROOT := $( OUT_DIR) /host
2009-03-04 04:28:42 +01:00
2018-03-28 23:33:10 +02:00
.KATI_READONLY := SOONG_OUT_DIR TARGET_OUT_ROOT HOST_OUT_ROOT
2014-04-17 19:03:35 +02:00
# We want to avoid two host bin directories in multilib build.
2017-09-08 23:29:51 +02:00
HOST_OUT := $( HOST_OUT_ROOT) /$( HOST_OS) -$( HOST_PREBUILT_ARCH)
2016-05-28 00:15:47 +02:00
SOONG_HOST_OUT := $( SOONG_OUT_DIR) /host/$( HOST_OS) -$( HOST_PREBUILT_ARCH)
2009-03-04 04:28:42 +01:00
2017-09-08 23:29:51 +02:00
HOST_CROSS_OUT := $( HOST_OUT_ROOT) /windows-$( HOST_PREBUILT_ARCH)
2010-04-17 02:50:09 +02:00
2018-03-28 23:33:10 +02:00
.KATI_READONLY := HOST_OUT SOONG_HOST_OUT HOST_CROSS_OUT
2011-07-12 07:11:46 +02:00
TARGET_PRODUCT_OUT_ROOT := $( TARGET_OUT_ROOT) /product
2009-03-04 04:28:42 +01: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)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_PRODUCT_OUT_ROOT TARGET_COMMON_OUT_ROOT HOST_COMMON_OUT_ROOT PRODUCT_OUT
2009-03-04 04:28:42 +01:00
OUT_DOCS := $( TARGET_COMMON_OUT_ROOT) /docs
2017-10-04 19:20:20 +02:00
OUT_NDK_DOCS := $( TARGET_COMMON_OUT_ROOT) /ndk-docs
2018-03-28 23:33:10 +02:00
.KATI_READONLY := OUT_DOCS OUT_NDK_DOCS
$( call KATI_obsolete ,BUILD_OUT ,Use HOST_OUT instead )
2009-03-04 04:28:42 +01:00
2018-03-28 23:33:10 +02:00
BUILD_OUT_EXECUTABLES := $( HOST_OUT) /bin
2016-05-28 00:15:47 +02:00
SOONG_HOST_OUT_EXECUTABLES := $( SOONG_HOST_OUT) /bin
2018-03-28 23:33:10 +02:00
.KATI_READONLY := BUILD_OUT_EXECUTABLES SOONG_HOST_OUT_EXECUTABLES
2010-04-17 02:50:09 +02:00
2014-01-14 01:14:20 +01:00
HOST_OUT_EXECUTABLES := $( HOST_OUT) /bin
2014-07-01 02:06:21 +02:00
HOST_OUT_SHARED_LIBRARIES := $( HOST_OUT) /lib64
2016-02-13 09:19:40 +01:00
HOST_OUT_RENDERSCRIPT_BITCODE := $( HOST_OUT_SHARED_LIBRARIES)
2014-01-14 01:14:20 +01:00
HOST_OUT_JAVA_LIBRARIES := $( HOST_OUT) /framework
2009-04-10 04:31:12 +02:00
HOST_OUT_SDK_ADDON := $( HOST_OUT) /sdk_addon
Add NATIVE_TESTS class, move host native tests
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-02 22:54:51 +01:00
HOST_OUT_NATIVE_TESTS := $( HOST_OUT) /nativetest64
2016-09-12 22:56:50 +02:00
HOST_OUT_COVERAGE := $( HOST_OUT) /coverage
2018-03-17 06:09:50 +01:00
HOST_OUT_TESTCASES := $( HOST_OUT) /testcases
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_OUT_EXECUTABLES \
HOST_OUT_SHARED_LIBRARIES \
HOST_OUT_RENDERSCRIPT_BITCODE \
HOST_OUT_JAVA_LIBRARIES \
HOST_OUT_SDK_ADDON \
HOST_OUT_NATIVE_TESTS \
HOST_OUT_COVERAGE \
HOST_OUT_TESTCASES
2009-03-04 04:28:42 +01:00
2015-08-14 21:59:50 +02:00
HOST_CROSS_OUT_EXECUTABLES := $( HOST_CROSS_OUT) /bin
HOST_CROSS_OUT_SHARED_LIBRARIES := $( HOST_CROSS_OUT) /lib
Add NATIVE_TESTS class, move host native tests
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-02 22:54:51 +01:00
HOST_CROSS_OUT_NATIVE_TESTS := $( HOST_CROSS_OUT) /nativetest
2016-09-12 22:56:50 +02:00
HOST_CROSS_OUT_COVERAGE := $( HOST_CROSS_OUT) /coverage
2018-03-17 06:09:50 +01:00
HOST_CROSS_OUT_TESTCASES := $( HOST_CROSS_OUT) /testcases
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_CROSS_OUT_EXECUTABLES \
HOST_CROSS_OUT_SHARED_LIBRARIES \
HOST_CROSS_OUT_NATIVE_TESTS \
HOST_CROSS_OUT_COVERAGE \
HOST_CROSS_OUT_TESTCASES
2015-08-14 21:59:50 +02:00
2009-03-04 04:28:42 +01:00
HOST_OUT_INTERMEDIATES := $( HOST_OUT) /obj
2014-01-14 01:14:20 +01:00
HOST_OUT_NOTICE_FILES := $( HOST_OUT_INTERMEDIATES) /NOTICE_FILES
2009-03-04 04:28:42 +01:00
HOST_OUT_COMMON_INTERMEDIATES := $( HOST_COMMON_OUT_ROOT) /obj
2013-11-14 00:56:18 +01:00
HOST_OUT_FAKE := $( HOST_OUT) /fake_packages
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_OUT_INTERMEDIATES \
HOST_OUT_NOTICE_FILES \
HOST_OUT_COMMON_INTERMEDIATES \
HOST_OUT_FAKE
2009-03-04 04:28:42 +01:00
2016-08-02 02:41:49 +02:00
# Nano environment config
i n c l u d e $( BUILD_SYSTEM ) / a u x _ c o n f i g . m k
2015-08-14 21:59:50 +02:00
HOST_CROSS_OUT_INTERMEDIATES := $( HOST_CROSS_OUT) /obj
HOST_CROSS_OUT_NOTICE_FILES := $( HOST_CROSS_OUT_INTERMEDIATES) /NOTICE_FILES
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_CROSS_OUT_INTERMEDIATES \
HOST_CROSS_OUT_NOTICE_FILES
2015-08-14 21:59:50 +02:00
2014-01-25 08:17:21 +01:00
HOST_OUT_GEN := $( HOST_OUT) /gen
HOST_OUT_COMMON_GEN := $( HOST_COMMON_OUT_ROOT) /gen
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_OUT_GEN \
HOST_OUT_COMMON_GEN
2014-01-25 08:17:21 +01:00
2015-08-14 21:59:50 +02:00
HOST_CROSS_OUT_GEN := $( HOST_CROSS_OUT) /gen
2018-03-28 23:33:10 +02:00
.KATI_READONLY := HOST_CROSS_OUT_GEN
2015-08-14 21:59:50 +02:00
2017-11-13 22:38:17 +01:00
HOST_OUT_TEST_CONFIG := $( HOST_OUT) /test_config
2018-03-28 23:33:10 +02:00
.KATI_READONLY := HOST_OUT_TEST_CONFIG
2017-11-13 22:38:17 +01:00
2014-04-17 19:03:35 +02: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
2014-05-20 23:43:51 +02:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_SHARED_LIBRARIES := $( HOST_OUT) /lib
2014-04-17 19:03:35 +02:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_EXECUTABLES := $( HOST_OUT_EXECUTABLES)
2015-05-05 03:17:52 +02:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_JAVA_LIBRARIES := $( HOST_OUT_JAVA_LIBRARIES)
Add NATIVE_TESTS class, move host native tests
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-02 22:54:51 +01:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_NATIVE_TESTS := $( HOST_OUT) /nativetest
2017-01-26 00:11:55 +01:00
$(HOST_2ND_ARCH_VAR_PREFIX)HOST_OUT_TESTCASES := $( HOST_OUT_TESTCASES)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_2ND_ARCH_VAR_PREFIX \
HOST_2ND_ARCH_MODULE_SUFFIX \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_INTERMEDIATES \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_SHARED_LIBRARIES \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_EXECUTABLES \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_JAVA_LIBRARIES \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_NATIVE_TESTS \
$( HOST_2ND_ARCH_VAR_PREFIX) HOST_OUT_TESTCASES
2014-04-17 19:03:35 +02:00
2014-06-10 21:04:56 +02:00
# The default host library path.
# It always points to the path where we build libraries in the default bitness.
2014-08-14 20:03:56 +02:00
HOST_LIBRARY_PATH := $( HOST_OUT_SHARED_LIBRARIES)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := HOST_LIBRARY_PATH
2014-04-17 19:03:35 +02:00
2016-02-06 01:20:19 +01: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_SHARED_LIBRARIES := $( HOST_CROSS_OUT) /lib64
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_EXECUTABLES := $( HOST_CROSS_OUT_EXECUTABLES)
Add NATIVE_TESTS class, move host native tests
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
2016-03-02 22:54:51 +01:00
$(HOST_CROSS_2ND_ARCH_VAR_PREFIX)HOST_CROSS_OUT_NATIVE_TESTS := $( HOST_CROSS_OUT) /nativetest64
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
HOST_CROSS_2ND_ARCH_VAR_PREFIX \
HOST_CROSS_2ND_ARCH_MODULE_SUFFIX \
$( HOST_CROSS_2ND_ARCH_VAR_PREFIX) HOST_CROSS_OUT_INTERMEDIATES \
$( HOST_CROSS_2ND_ARCH_VAR_PREFIX) HOST_CROSS_OUT_SHARED_LIBRARIES \
$( HOST_CROSS_2ND_ARCH_VAR_PREFIX) HOST_CROSS_OUT_EXECUTABLES \
$( HOST_CROSS_2ND_ARCH_VAR_PREFIX) HOST_CROSS_OUT_NATIVE_TESTS
2016-02-06 01:20:19 +01:00
2017-05-10 04:36:54 +02:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
TARGET_OUT_INTERMEDIATES := $( PRODUCT_OUT) /obj_asan
e l s e
TARGET_OUT_INTERMEDIATES := $( PRODUCT_OUT) /obj
e n d i f
2014-01-14 01:14:20 +01:00
TARGET_OUT_HEADERS := $( TARGET_OUT_INTERMEDIATES) /include
2018-09-05 20:01:12 +02:00
.KATI_READONLY := TARGET_OUT_INTERMEDIATES TARGET_OUT_HEADERS
2017-05-10 04:36:54 +02:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
TARGET_OUT_COMMON_INTERMEDIATES := $( TARGET_COMMON_OUT_ROOT) /obj_asan
e l s e
TARGET_OUT_COMMON_INTERMEDIATES := $( TARGET_COMMON_OUT_ROOT) /obj
e n d i f
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_COMMON_INTERMEDIATES
2009-03-04 04:28:42 +01:00
2014-01-25 08:17:21 +01:00
TARGET_OUT_GEN := $( PRODUCT_OUT) /gen
TARGET_OUT_COMMON_GEN := $( TARGET_COMMON_OUT_ROOT) /gen
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_GEN TARGET_OUT_COMMON_GEN
2014-01-25 08:17:21 +01:00
2011-10-28 00:18:39 +02:00
TARGET_OUT := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_SYSTEM)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT
2015-09-18 20:54:43 +02:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
2017-03-30 00:32:04 +02:00
target_out_shared_libraries_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /system
2017-06-16 19:24:54 +02:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
target_out_app_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /system
e l s e
target_out_app_base := $( TARGET_OUT)
e n d i f
2015-06-12 02:32:31 +02:00
e l s e
target_out_shared_libraries_base := $( TARGET_OUT)
2017-06-16 19:24:54 +02:00
target_out_app_base := $( TARGET_OUT)
2015-06-12 02:32:31 +02:00
e n d i f
2014-01-14 01:14:20 +01:00
TARGET_OUT_EXECUTABLES := $( TARGET_OUT) /bin
TARGET_OUT_OPTIONAL_EXECUTABLES := $( TARGET_OUT) /xbin
2014-07-09 02:07:36 +02:00
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
2014-01-14 01:14:20 +01:00
# /system/lib always contains 32-bit libraries,
# and /system/lib64 (if present) always contains 64-bit libraries.
2015-06-12 02:32:31 +02:00
TARGET_OUT_SHARED_LIBRARIES := $( target_out_shared_libraries_base) /lib64
2014-01-14 01:14:20 +01:00
e l s e
2015-06-12 02:32:31 +02:00
TARGET_OUT_SHARED_LIBRARIES := $( target_out_shared_libraries_base) /lib
2014-01-14 01:14:20 +01:00
e n d i f
2016-02-13 09:19:40 +01:00
TARGET_OUT_RENDERSCRIPT_BITCODE := $( TARGET_OUT_SHARED_LIBRARIES)
2014-01-14 01:14:20 +01:00
TARGET_OUT_JAVA_LIBRARIES := $( TARGET_OUT) /framework
2017-06-16 19:24:54 +02:00
TARGET_OUT_APPS := $( target_out_app_base) /app
TARGET_OUT_APPS_PRIVILEGED := $( target_out_app_base) /priv-app
2009-03-04 04:28:42 +01:00
TARGET_OUT_KEYLAYOUT := $( TARGET_OUT) /usr/keylayout
TARGET_OUT_KEYCHARS := $( TARGET_OUT) /usr/keychars
TARGET_OUT_ETC := $( TARGET_OUT) /etc
2014-01-14 01:14:20 +01:00
TARGET_OUT_NOTICE_FILES := $( TARGET_OUT_INTERMEDIATES) /NOTICE_FILES
2010-09-28 02:37:17 +02:00
TARGET_OUT_FAKE := $( PRODUCT_OUT) /fake_packages
2017-01-26 00:11:55 +01:00
TARGET_OUT_TESTCASES := $( PRODUCT_OUT) /testcases
2017-11-13 22:38:17 +01:00
TARGET_OUT_TEST_CONFIG := $( PRODUCT_OUT) /test_config
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_EXECUTABLES \
TARGET_OUT_OPTIONAL_EXECUTABLES \
TARGET_OUT_SHARED_LIBRARIES \
TARGET_OUT_RENDERSCRIPT_BITCODE \
TARGET_OUT_JAVA_LIBRARIES \
TARGET_OUT_APPS \
TARGET_OUT_APPS_PRIVILEGED \
TARGET_OUT_KEYLAYOUT \
TARGET_OUT_KEYCHARS \
TARGET_OUT_ETC \
TARGET_OUT_NOTICE_FILES \
TARGET_OUT_FAKE \
TARGET_OUT_TESTCASES \
TARGET_OUT_TEST_CONFIG
2009-03-04 04:28:42 +01:00
2017-06-16 19:24:54 +02:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
TARGET_OUT_SYSTEM_OTHER := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_SYSTEM_OTHER)
e l s e
2016-06-16 23:47:10 +02:00
TARGET_OUT_SYSTEM_OTHER := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_SYSTEM_OTHER)
2017-06-16 19:24:54 +02:00
e n d i f
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_SYSTEM_OTHER
2016-06-16 23:47:10 +02:00
2013-12-27 20:09:36 +01:00
# Out for TARGET_2ND_ARCH
2014-06-10 21:04:56 +02:00
TARGET_2ND_ARCH_VAR_PREFIX := $( HOST_2ND_ARCH_VAR_PREFIX)
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
# With this you can reference the arm binary translation library with libfoo_arm in PRODUCT_PACKAGES.
TARGET_2ND_ARCH_MODULE_SUFFIX := _$( TARGET_2ND_ARCH)
e l s e
2014-06-10 21:04:56 +02:00
TARGET_2ND_ARCH_MODULE_SUFFIX := $( HOST_2ND_ARCH_MODULE_SUFFIX)
2016-03-17 03:53:19 +01:00
e n d i f
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_2ND_ARCH_VAR_PREFIX TARGET_2ND_ARCH_MODULE_SUFFIX
2017-05-10 04:36:54 +02:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_INTERMEDIATES := $( PRODUCT_OUT) /obj_$( TARGET_2ND_ARCH) _asan
e l s e
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_INTERMEDIATES := $( PRODUCT_OUT) /obj_$( TARGET_2ND_ARCH)
e n d i f
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES := $( target_out_shared_libraries_base) /lib/$( TARGET_2ND_ARCH)
e l s e
2015-06-12 02:32:31 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_SHARED_LIBRARIES := $( target_out_shared_libraries_base) /lib
2016-03-17 03:53:19 +01:00
e n d i f
2016-02-13 09:19:40 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_RENDERSCRIPT_BITCODE := $( $( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_SHARED_LIBRARIES)
2014-01-18 01:17:28 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_EXECUTABLES := $( TARGET_OUT_EXECUTABLES)
2014-01-24 22:37:07 +01: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)
2017-01-26 00:11:55 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_TESTCASES := $( TARGET_OUT_TESTCASES)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_INTERMEDIATES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_SHARED_LIBRARIES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_RENDERSCRIPT_BITCODE \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_EXECUTABLES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_APPS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_APPS_PRIVILEGED \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_TESTCASES
2013-12-27 20:09:36 +01:00
2011-10-28 00:18:39 +02:00
TARGET_OUT_DATA := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_DATA)
2014-01-14 01:14:20 +01: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
2009-03-04 04:28:42 +01:00
TARGET_OUT_DATA_KEYLAYOUT := $( TARGET_OUT_KEYLAYOUT)
TARGET_OUT_DATA_KEYCHARS := $( TARGET_OUT_KEYCHARS)
TARGET_OUT_DATA_ETC := $( TARGET_OUT_ETC)
2014-07-09 02:07:36 +02:00
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
TARGET_OUT_DATA_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest64
2016-04-12 11:22:06 +02:00
TARGET_OUT_DATA_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest64
2017-07-11 23:59:30 +02:00
TARGET_OUT_VENDOR_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest64$( TARGET_VENDOR_TEST_SUFFIX)
TARGET_OUT_VENDOR_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest64$( TARGET_VENDOR_TEST_SUFFIX)
2014-07-09 02:07:36 +02:00
e l s e
2010-07-20 20:08:47 +02:00
TARGET_OUT_DATA_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest
2016-04-12 11:22:06 +02:00
TARGET_OUT_DATA_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest
2017-07-11 23:59:30 +02:00
TARGET_OUT_VENDOR_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest$( TARGET_VENDOR_TEST_SUFFIX)
TARGET_OUT_VENDOR_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest$( TARGET_VENDOR_TEST_SUFFIX)
2014-07-09 02:07:36 +02:00
e n d i f
2012-07-13 22:47:09 +02:00
TARGET_OUT_DATA_FAKE := $( TARGET_OUT_DATA) /fake_packages
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_DATA \
TARGET_OUT_DATA_EXECUTABLES \
TARGET_OUT_DATA_SHARED_LIBRARIES \
TARGET_OUT_DATA_JAVA_LIBRARIES \
TARGET_OUT_DATA_APPS \
TARGET_OUT_DATA_KEYLAYOUT \
TARGET_OUT_DATA_KEYCHARS \
TARGET_OUT_DATA_ETC \
TARGET_OUT_DATA_NATIVE_TESTS \
TARGET_OUT_DATA_METRIC_TESTS \
TARGET_OUT_VENDOR_NATIVE_TESTS \
TARGET_OUT_VENDOR_METRIC_TESTS \
TARGET_OUT_DATA_FAKE
2009-03-04 04:28:42 +01:00
2014-01-24 00:09:04 +01: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)
2014-01-24 22:37:07 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_APPS := $( TARGET_OUT_DATA_APPS)
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest/$( TARGET_2ND_ARCH)
2016-04-12 22:06:20 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest/$( TARGET_2ND_ARCH)
2017-07-11 23:59:30 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest/$( TARGET_2ND_ARCH) $( TARGET_VENDOR_TEST_SUFFIX)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest/$( TARGET_2ND_ARCH) $( TARGET_VENDOR_TEST_SUFFIX)
2016-03-17 03:53:19 +01:00
e l s e
2014-07-09 02:07:36 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest
2016-04-12 11:22:06 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_DATA_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest
2017-07-11 23:59:30 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_NATIVE_TESTS := $( TARGET_OUT_DATA) /nativetest$( TARGET_VENDOR_TEST_SUFFIX)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_METRIC_TESTS := $( TARGET_OUT_DATA) /benchmarktest$( TARGET_VENDOR_TEST_SUFFIX)
2016-03-17 03:53:19 +01:00
e n d i f
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_DATA_EXECUTABLES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_DATA_SHARED_LIBRARIES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_DATA_APPS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_DATA_NATIVE_TESTS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_DATA_METRIC_TESTS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_NATIVE_TESTS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_METRIC_TESTS \
2014-01-24 00:09:04 +01:00
2011-11-04 19:37:01 +01:00
TARGET_OUT_CACHE := $( PRODUCT_OUT) /cache
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_CACHE
2011-11-04 19:37:01 +01:00
2011-10-28 00:18:39 +02:00
TARGET_OUT_VENDOR := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_VENDOR)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_VENDOR
2015-09-18 20:54:43 +02:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
2018-10-02 14:16:05 +02:00
target_out_vendor_shared_libraries_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_VENDOR)
2017-06-16 19:24:54 +02:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
2018-10-02 14:16:05 +02:00
target_out_vendor_app_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_VENDOR)
2017-06-16 19:24:54 +02:00
e l s e
target_out_vendor_app_base := $( TARGET_OUT_VENDOR)
e n d i f
2015-06-30 23:02:02 +02:00
e l s e
target_out_vendor_shared_libraries_base := $( TARGET_OUT_VENDOR)
2017-06-16 19:24:54 +02:00
target_out_vendor_app_base := $( TARGET_OUT_VENDOR)
2015-06-30 23:02:02 +02:00
e n d i f
2014-01-14 01:14:20 +01:00
TARGET_OUT_VENDOR_EXECUTABLES := $( TARGET_OUT_VENDOR) /bin
TARGET_OUT_VENDOR_OPTIONAL_EXECUTABLES := $( TARGET_OUT_VENDOR) /xbin
2014-07-09 02:07:36 +02:00
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
2015-06-30 23:02:02 +02:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES := $( target_out_vendor_shared_libraries_base) /lib64
2014-01-14 01:14:20 +01:00
e l s e
2015-06-30 23:02:02 +02:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES := $( target_out_vendor_shared_libraries_base) /lib
2014-01-14 01:14:20 +01:00
e n d i f
2017-03-02 04:39:19 +01:00
TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE := $( TARGET_OUT_VENDOR_SHARED_LIBRARIES)
2014-01-14 01:14:20 +01:00
TARGET_OUT_VENDOR_JAVA_LIBRARIES := $( TARGET_OUT_VENDOR) /framework
2017-06-16 19:24:54 +02:00
TARGET_OUT_VENDOR_APPS := $( target_out_vendor_app_base) /app
TARGET_OUT_VENDOR_APPS_PRIVILEGED := $( target_out_vendor_app_base) /priv-app
2011-09-13 22:57:26 +02:00
TARGET_OUT_VENDOR_ETC := $( TARGET_OUT_VENDOR) /etc
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_VENDOR_EXECUTABLES \
TARGET_OUT_VENDOR_OPTIONAL_EXECUTABLES \
TARGET_OUT_VENDOR_SHARED_LIBRARIES \
TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE \
TARGET_OUT_VENDOR_JAVA_LIBRARIES \
TARGET_OUT_VENDOR_APPS \
TARGET_OUT_VENDOR_APPS_PRIVILEGED \
TARGET_OUT_VENDOR_ETC
2011-09-13 22:57:26 +02:00
2014-01-24 00:09:04 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_EXECUTABLES := $( TARGET_OUT_VENDOR_EXECUTABLES)
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
2016-07-01 05:20:38 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $( target_out_vendor_shared_libraries_base) /lib/$( TARGET_2ND_ARCH)
2016-03-17 03:53:19 +01:00
e l s e
2016-07-01 05:20:38 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_SHARED_LIBRARIES := $( target_out_vendor_shared_libraries_base) /lib
2016-03-17 03:53:19 +01:00
e n d i f
2017-03-02 04:39:19 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE := $( $( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_SHARED_LIBRARIES)
2014-01-24 22:37:07 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS := $( TARGET_OUT_VENDOR_APPS)
2016-07-20 11:51:56 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS_PRIVILEGED := $( TARGET_OUT_VENDOR_APPS_PRIVILEGED)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_EXECUTABLES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_SHARED_LIBRARIES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_RENDERSCRIPT_BITCODE \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_APPS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_VENDOR_APPS_PRIVILEGED
2014-01-16 01:02:16 +01:00
2014-03-12 01:13:27 +01:00
TARGET_OUT_OEM := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_OEM)
2014-06-26 23:12:35 +02: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 02:30:39 +01:00
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
2014-06-26 23:12:35 +02:00
TARGET_OUT_OEM_SHARED_LIBRARIES := $( TARGET_OUT_OEM) /lib64
e l s e
TARGET_OUT_OEM_SHARED_LIBRARIES := $( TARGET_OUT_OEM) /lib
e n d i f
2014-03-12 01:13:27 +01:00
# We don't expect Java libraries in the oem.img.
# TARGET_OUT_OEM_JAVA_LIBRARIES:= $(TARGET_OUT_OEM)/framework
2014-06-26 23:12:35 +02:00
TARGET_OUT_OEM_APPS := $( TARGET_OUT_OEM) /app
2014-03-12 01:13:27 +01:00
TARGET_OUT_OEM_ETC := $( TARGET_OUT_OEM) /etc
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_OEM \
TARGET_OUT_OEM_EXECUTABLES \
TARGET_OUT_OEM_SHARED_LIBRARIES \
TARGET_OUT_OEM_APPS \
TARGET_OUT_OEM_ETC
2014-03-12 01:13:27 +01:00
2014-06-26 23:12:35 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_EXECUTABLES := $( TARGET_OUT_OEM_EXECUTABLES)
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_SHARED_LIBRARIES := $( TARGET_OUT_OEM) /lib/$( TARGET_2ND_ARCH)
e l s e
2014-06-26 23:12:35 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_SHARED_LIBRARIES := $( TARGET_OUT_OEM) /lib
2016-03-17 03:53:19 +01:00
e n d i f
2014-06-26 23:12:35 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_OEM_APPS := $( TARGET_OUT_OEM_APPS)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_OEM_EXECUTABLES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_OEM_SHARED_LIBRARIES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_OEM_APPS \
2014-06-26 23:12:35 +02:00
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 02:30:39 +01:00
TARGET_OUT_ODM := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ODM)
2017-11-14 16:42:30 +01:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
2018-10-02 14:16:05 +02:00
target_out_odm_shared_libraries_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_OEM)
2017-11-14 16:42:30 +01:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
2018-10-02 14:16:05 +02:00
target_out_odm_app_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_OEM)
2017-11-14 16:42:30 +01:00
e l s e
target_out_odm_app_base := $( TARGET_OUT_ODM)
e n d i f
e l s e
target_out_odm_shared_libraries_base := $( TARGET_OUT_ODM)
target_out_odm_app_base := $( TARGET_OUT_ODM)
e n d i f
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 02:30:39 +01:00
TARGET_OUT_ODM_EXECUTABLES := $( TARGET_OUT_ODM) /bin
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_OPTIONAL_EXECUTABLES := $( TARGET_OUT_ODM) /xbin
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 02:30:39 +01:00
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_SHARED_LIBRARIES := $( target_out_odm_shared_libraries_base) /lib64
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 02:30:39 +01:00
e l s e
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_SHARED_LIBRARIES := $( target_out_odm_shared_libraries_base) /lib
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 02:30:39 +01:00
e n d i f
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_RENDERSCRIPT_BITCODE := $( TARGET_OUT_ODM_SHARED_LIBRARIES)
TARGET_OUT_ODM_JAVA_LIBRARIES := $( TARGET_OUT_ODM) /framework
TARGET_OUT_ODM_APPS := $( target_out_odm_app_base) /app
TARGET_OUT_ODM_APPS_PRIVILEGED := $( target_out_odm_app_base) /priv-app
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 02:30:39 +01:00
TARGET_OUT_ODM_ETC := $( TARGET_OUT_ODM) /etc
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_ODM \
TARGET_OUT_ODM_EXECUTABLES \
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_OPTIONAL_EXECUTABLES \
2018-03-28 23:33:10 +02:00
TARGET_OUT_ODM_SHARED_LIBRARIES \
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_RENDERSCRIPT_BITCODE \
TARGET_OUT_ODM_JAVA_LIBRARIES \
2018-03-28 23:33:10 +02:00
TARGET_OUT_ODM_APPS \
2017-11-14 16:42:30 +01:00
TARGET_OUT_ODM_APPS_PRIVILEGED \
2018-03-28 23:33:10 +02:00
TARGET_OUT_ODM_ETC
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 02:30:39 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_EXECUTABLES := $( TARGET_OUT_ODM_EXECUTABLES)
2016-03-17 03:53:19 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
2017-11-14 16:42:30 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_SHARED_LIBRARIES := $( target_out_odm_shared_libraries_base) /lib/$( TARGET_2ND_ARCH)
2016-03-17 03:53:19 +01:00
e l s e
2017-11-14 16:42:30 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_SHARED_LIBRARIES := $( target_out_odm_shared_libraries_base) /lib
2016-03-17 03:53:19 +01:00
e n d i f
2017-11-14 16:42:30 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_RENDERSCRIPT_BITCODE := $( $( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_SHARED_LIBRARIES)
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 02:30:39 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_APPS := $( TARGET_OUT_ODM_APPS)
2017-11-14 16:42:30 +01:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_ODM_APPS_PRIVILEGED := $( TARGET_OUT_ODM_APPS_PRIVILEGED)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_EXECUTABLES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_SHARED_LIBRARIES \
2017-11-14 16:42:30 +01:00
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_RENDERSCRIPT_BITCODE \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_APPS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_ODM_APPS_PRIVILEGED
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 02:30:39 +01:00
2017-11-27 09:04:47 +01:00
TARGET_OUT_PRODUCT := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_PRODUCT)
2018-06-25 03:56:01 +02:00
TARGET_OUT_PRODUCT_EXECUTABLES := $( TARGET_OUT_PRODUCT) /bin
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_PRODUCT
2017-11-27 09:04:47 +01:00
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
2018-10-02 14:16:05 +02:00
target_out_product_shared_libraries_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_PRODUCT)
2017-11-27 09:04:47 +01:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
2018-10-02 14:16:05 +02:00
target_out_product_app_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_PRODUCT)
2017-11-27 09:04:47 +01:00
e l s e
target_out_product_app_base := $( TARGET_OUT_PRODUCT)
e n d i f
e l s e
2018-05-04 04:20:43 +02:00
target_out_product_shared_libraries_base := $( TARGET_OUT_PRODUCT)
2017-11-27 09:04:47 +01:00
target_out_product_app_base := $( TARGET_OUT_PRODUCT)
e n d i f
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
TARGET_OUT_PRODUCT_SHARED_LIBRARIES := $( target_out_product_shared_libraries_base) /lib64
e l s e
TARGET_OUT_PRODUCT_SHARED_LIBRARIES := $( target_out_product_shared_libraries_base) /lib
e n d i f
2018-03-28 23:33:10 +02:00
TARGET_OUT_PRODUCT_JAVA_LIBRARIES := $( TARGET_OUT_PRODUCT) /framework
2017-11-27 09:04:47 +01:00
TARGET_OUT_PRODUCT_APPS := $( target_out_product_app_base) /app
TARGET_OUT_PRODUCT_APPS_PRIVILEGED := $( target_out_product_app_base) /priv-app
TARGET_OUT_PRODUCT_ETC := $( TARGET_OUT_PRODUCT) /etc
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
2018-06-25 03:56:01 +02:00
TARGET_OUT_PRODUCT_EXECUTABLES \
2018-03-28 23:33:10 +02:00
TARGET_OUT_PRODUCT_SHARED_LIBRARIES \
TARGET_OUT_PRODUCT_JAVA_LIBRARIES \
TARGET_OUT_PRODUCT_APPS \
TARGET_OUT_PRODUCT_APPS_PRIVILEGED \
TARGET_OUT_PRODUCT_ETC
2017-11-27 09:04:47 +01:00
2018-06-25 03:56:01 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_EXECUTABLES := $( TARGET_OUT_PRODUCT_EXECUTABLES)
2017-11-27 09:04:47 +01:00
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SHARED_LIBRARIES := $( target_out_product_shared_libraries_base) /lib/$( TARGET_2ND_ARCH)
e l s e
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SHARED_LIBRARIES := $( target_out_product_shared_libraries_base) /lib
e n d i f
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_APPS := $( TARGET_OUT_PRODUCT_APPS)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_APPS_PRIVILEGED := $( TARGET_OUT_PRODUCT_APPS_PRIVILEGED)
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
2018-06-25 03:56:01 +02:00
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_PRODUCT_EXECUTABLES \
2018-03-28 23:33:10 +02:00
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_PRODUCT_SHARED_LIBRARIES \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_PRODUCT_APPS \
$( TARGET_2ND_ARCH_VAR_PREFIX) TARGET_OUT_PRODUCT_APPS_PRIVILEGED
2017-11-27 09:04:47 +01:00
2018-05-29 14:09:01 +02:00
TARGET_OUT_PRODUCT_SERVICES := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_PRODUCT_SERVICES)
i f n e q ( $( filter address ,$ ( SANITIZE_TARGET ) ) , )
2018-10-02 14:16:05 +02:00
target_out_product_services_shared_libraries_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_PRODUCT_SERVICES)
2018-05-29 14:09:01 +02:00
i f e q ( $( SANITIZE_LITE ) , t r u e )
# When using SANITIZE_LITE, APKs must not be packaged with sanitized libraries, as they will not
# work with unsanitized app_process. For simplicity, generate APKs into /data/asan/.
2018-10-02 14:16:05 +02:00
target_out_product_services_app_base := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ASAN) /$( TARGET_COPY_OUT_PRODUCT_SERVICES)
2018-05-29 14:09:01 +02:00
e l s e
2018-07-27 01:02:52 +02:00
target_out_product_services_app_base := $( TARGET_OUT_PRODUCT_SERVICES)
2018-05-29 14:09:01 +02:00
e n d i f
e l s e
2018-07-27 01:02:52 +02:00
target_out_product_services_shared_libraries_base := $( TARGET_OUT_PRODUCT_SERVICES)
target_out_product_services_app_base := $( TARGET_OUT_PRODUCT_SERVICES)
2018-05-29 14:09:01 +02:00
e n d i f
i f e q ( $( TARGET_IS_ 64_BIT ) , t r u e )
2018-07-27 01:02:52 +02:00
TARGET_OUT_PRODUCT_SERVICES_SHARED_LIBRARIES := $( target_out_product_services_shared_libraries_base) /lib64
2018-05-29 14:09:01 +02:00
e l s e
2018-07-27 01:02:52 +02:00
TARGET_OUT_PRODUCT_SERVICES_SHARED_LIBRARIES := $( target_out_product_services_shared_libraries_base) /lib
2018-05-29 14:09:01 +02:00
e n d i f
TARGET_OUT_PRODUCT_SERVICES_JAVA_LIBRARIES := $( TARGET_OUT_PRODUCT_SERVICES) /framework
2018-07-27 01:02:52 +02:00
TARGET_OUT_PRODUCT_SERVICES_APPS := $( target_out_product_services_app_base) /app
TARGET_OUT_PRODUCT_SERVICES_APPS_PRIVILEGED := $( target_out_product_services_app_base) /priv-app
2018-05-29 14:09:01 +02:00
TARGET_OUT_PRODUCT_SERVICES_ETC := $( TARGET_OUT_PRODUCT_SERVICES) /etc
i f e q ( $( TARGET_TRANSLATE_ 2ND_ARCH ) , t r u e )
2018-07-27 01:02:52 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SERVICES_SHARED_LIBRARIES := $( target_out_product_services_shared_libraries_base) /lib/$( TARGET_2ND_ARCH)
2018-05-29 14:09:01 +02:00
e l s e
2018-07-27 01:02:52 +02:00
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SERVICES_SHARED_LIBRARIES := $( target_out_product_services_shared_libraries_base) /lib
2018-05-29 14:09:01 +02:00
e n d i f
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SERVICES_APPS := $( TARGET_OUT_PRODUCT_SERVICES_APPS)
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_PRODUCT_SERVICES_APPS_PRIVILEGED := $( TARGET_OUT_PRODUCT_SERVICES_APPS_PRIVILEGED)
2015-09-25 03:12:33 +02:00
TARGET_OUT_BREAKPAD := $( PRODUCT_OUT) /breakpad
2018-03-28 23:33:10 +02:00
.KATI_READONLY := TARGET_OUT_BREAKPAD
2015-09-25 03:12:33 +02:00
2009-03-04 04:28:42 +01: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
2014-06-20 22:33:36 +02:00
TARGET_OUT_VENDOR_SHARED_LIBRARIES_UNSTRIPPED := $( TARGET_OUT_UNSTRIPPED) /$( TARGET_COPY_OUT_VENDOR) /lib
2009-03-04 04:28:42 +01: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
2016-09-16 02:32:13 +02:00
TARGET_OUT_COVERAGE := $( PRODUCT_OUT) /coverage
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_OUT_UNSTRIPPED \
TARGET_OUT_EXECUTABLES_UNSTRIPPED \
TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED \
TARGET_OUT_VENDOR_SHARED_LIBRARIES_UNSTRIPPED \
TARGET_ROOT_OUT_UNSTRIPPED \
TARGET_ROOT_OUT_SBIN_UNSTRIPPED \
TARGET_ROOT_OUT_BIN_UNSTRIPPED \
TARGET_OUT_COVERAGE
2009-03-04 04:28:42 +01:00
2018-08-09 23:26:00 +02:00
TARGET_RAMDISK_OUT := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_RAMDISK)
TARGET_RAMDISK_OUT_UNSTRIPPED := $( TARGET_OUT_UNSTRIPPED)
2011-10-28 00:18:39 +02:00
TARGET_ROOT_OUT := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_ROOT)
2009-03-04 04:28:42 +01: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
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_ROOT_OUT \
TARGET_ROOT_OUT_BIN \
TARGET_ROOT_OUT_SBIN \
TARGET_ROOT_OUT_ETC \
TARGET_ROOT_OUT_USR
2009-03-04 04:28:42 +01:00
2011-10-28 00:18:39 +02:00
TARGET_RECOVERY_OUT := $( PRODUCT_OUT) /$( TARGET_COPY_OUT_RECOVERY)
2009-03-04 04:28:42 +01:00
TARGET_RECOVERY_ROOT_OUT := $( TARGET_RECOVERY_OUT) /root
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_RECOVERY_OUT \
TARGET_RECOVERY_ROOT_OUT
2009-03-04 04:28:42 +01:00
TARGET_SYSLOADER_OUT := $( PRODUCT_OUT) /sysloader
TARGET_SYSLOADER_ROOT_OUT := $( TARGET_SYSLOADER_OUT) /root
TARGET_SYSLOADER_SYSTEM_OUT := $( TARGET_SYSLOADER_OUT) /root/system
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_SYSLOADER_OUT \
TARGET_SYSLOADER_ROOT_OUT \
TARGET_SYSLOADER_SYSTEM_OUT
2009-03-04 04:28:42 +01:00
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
2018-03-28 23:33:10 +02:00
.KATI_READONLY := \
TARGET_INSTALLER_OUT \
TARGET_INSTALLER_DATA_OUT \
TARGET_INSTALLER_ROOT_OUT \
TARGET_INSTALLER_SYSTEM_OUT
2009-03-04 04:28:42 +01:00
2010-09-25 03:09:04 +02:00
COMMON_MODULE_CLASSES := TARGET-NOTICE_FILES HOST-NOTICE_FILES HOST-JAVA_LIBRARIES
2017-02-16 00:48:11 +01:00
PER_ARCH_MODULE_CLASSES := SHARED_LIBRARIES STATIC_LIBRARIES EXECUTABLES GYP RENDERSCRIPT_BITCODE NATIVE_TESTS HEADER_LIBRARIES
2018-03-28 23:33:10 +02:00
.KATI_READONLY := COMMON_MODULE_CLASSES PER_ARCH_MODULE_CLASSES
2009-03-04 04:28:42 +01:00
2017-10-12 10:35:14 +02:00
i f e q ( $( CALLED_FROM_SETUP ) , t r u e )
2017-02-18 19:32:13 +01:00
PRINT_BUILD_CONFIG ?= true
2009-03-04 04:28:42 +01:00
e n d i f