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

371 lines
11 KiB
Makefile
Raw Normal View History

auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
###########################################################
## Clear out values of all variables used by rule templates.
###########################################################
LOCAL_MODULE:=
LOCAL_MODULE_PATH:=
Support LOCAL_MODULE_RELATIVE_PATH Most users of LOCAL_MODULE_PATH are setting a subdirectory of the normal install path, for example to install HALs into system/lib/hw. This is problematic for multiarch builds, where the install location depends on the arch. Allow modules to specify LOCAL_MODULE_RELATIVE_PATH. HALs will generally use: LOCAL_MODULE_RELATIVE_PATH := hw Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
2014-01-25 11:23:40 +08:00
LOCAL_MODULE_RELATIVE_PATH :=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_MODULE_STEM:=
Speed up the full build. Now, by default, instead of fully building everything, we skip dexing the modules that aren't going to be included in the current build. This will slow down some of the incremental builds (like tests), but it improves the regular eng build from 27.5 minutes on my Mac Pro to 25 minutes. That's not as much of an improvement as I had hoped for, but it's still better. There is also a change in here that puts the java-source-list file which is used to get around limited command line lengths in the proper directory. Before this change, it was an accident that the directory for that file existed!
2009-07-18 03:33:40 +08:00
LOCAL_DONT_CHECK_MODULE:=
LOCAL_CHECKED_MODULE:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_BUILT_MODULE:=
LOCAL_BUILT_MODULE_STEM:=
OVERRIDE_BUILT_MODULE_PATH:=
LOCAL_INSTALLED_MODULE:=
Allow module to specify LOCAL_INSTALLED_MODULE_STEM With this change, you can install a shared library with module name foo as bar.so to the system.img with: LOCAL_INSTALLED_MODULE_STEM := bar.so Note that we in general still disallow a static/shared library to specify LOCAL_MODULE_STEM or LOCAL_BUILT_MODULE_STEM, because the build system uses LOCAL_MODULE to compute build time dependencies, such as export_includes, the -l linker flag etc. Also, if you use LOCAL_INSTALLED_MODULE_STEM to change the installed file name and if any other module links against this library, you may run into runtime error: the library name baked in to the binary is not the same as file name in the system image. Change-Id: I55b571c8139c3bda07a4a0e50cea0f20d8d6c168
2013-09-25 06:56:11 +08:00
LOCAL_INSTALLED_MODULE_STEM:=
Add tool to package up built modules. With this change, you can package up modules while avoiding installing them to the system.img or userdata.img. - build/core/tasks/tools/package-modules.mk You can use this template to package up modules into a zip file and preserve the installed file paths. - LOCAL_PICKUP_FILES, you can use this variable to package up extra files/directories. Bug: 13585955 Change-Id: I103042b24ccf17cf5dc90c016d97ed1dd293e50b
2014-05-06 07:46:52 +08:00
LOCAL_PICKUP_FILES:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_UNINSTALLABLE_MODULE:=
LOCAL_INTERMEDIATE_TARGETS:=
LOCAL_UNSTRIPPED_PATH:=
LOCAL_MODULE_CLASS:=
LOCAL_MODULE_SUFFIX:=
LOCAL_PACKAGE_NAME:=
LOCAL_OVERRIDES_PACKAGES:=
LOCAL_EXPORT_PACKAGE_RESOURCES:=
Get LOCAL_MANIFEST_PACKAGE_NAME working. Change-Id: Ieafbf2596252ee3a2fe5d1ad433e8863fbf84601
2010-02-06 12:36:42 +08:00
LOCAL_MANIFEST_PACKAGE_NAME:=
Support LOCAL_PACKAGE_SPLITS. Support LOCAL_PACKAGE_SPLITS, which accepts a list of resource lables and generates multiple apks. The build system sets up rules to sign and zipalign the split apks. Bug: 16319961 Change-Id: I344b3d1c7eb158c6d0df879093d666a89870aadd
2014-07-23 06:42:11 +08:00
LOCAL_PACKAGE_SPLITS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_REQUIRED_MODULES:=
LOCAL_MODULE_TAGS:=
LOCAL_SRC_FILES:=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_PREBUILT_OBJ_FILES:=
LOCAL_STATIC_JAVA_LIBRARIES:=
Add support for prebuilt AARs. - You can give a .aar as source file to a prebuilt static Java library module. The build system will set up dependencies and rules to extract classes.jar and other resource files. - To build against a prebuilt AAR module, use: LOCAL_STATIC_JAVA_AAR_LIBRARIES := <module names of aar prebuilt AARs> The build system will set up rules to merge the library's AndroidManifest.xml with the main AndroidManifest.xml, add the AAR's resource dirs and link/merge the AAR's classes.jar. Bug: 18168693 Change-Id: Ic2c1d20572a93bd98dbc72f8a39e26b459e442c2
2014-10-30 06:48:32 +08:00
LOCAL_STATIC_JAVA_AAR_LIBRARIES:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_STATIC_LIBRARIES:=
Add LOCAL_GROUP_STATIC_LIBRARIES Set LOCAL_GROUP_STATIC_LIBRARIES := true to group the static libraries, in case we need gcc flags "-Wl,--start-group" and "-Wl,--end-group" to fix circular references. Change-Id: I03c4901670112fcdd2bb0fe660b6924e5776fcf8
2011-04-26 05:22:41 +08:00
# Group static libraries with "-Wl,--start-group" and "-Wl,--end-group" when linking.
LOCAL_GROUP_STATIC_LIBRARIES:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_WHOLE_STATIC_LIBRARIES:=
Add support for LOCAL_EXPORT_*_LIBRARY_HEADERS Listing a library in any of: LOCAL_EXPORT_SHARED_LIBRARY_HEADERS LOCAL_EXPORT_STATIC_LIBRARY_HEADERS will cause the headers exported by that library to be exported from the current library target as well. This means that when library A's public headers include headers from library B, library C which consumes A no longer has to explicitly list A and B in its LOCAL_SHARED_LIBRARIES for the purpose of picking up B's headers. Bug: 27804373 Test: Introduced dependency on libbase to libbinder at the header level. Libraries that consume libbinder do not need to explicitly depend on libbase. Change-Id: If69079f058a4a182c5ef5a3c5ba15035570da22d
2016-04-12 03:40:36 +08:00
LOCAL_EXPORT_SHARED_LIBRARY_HEADERS:=
LOCAL_EXPORT_STATIC_LIBRARY_HEADERS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_SHARED_LIBRARIES:=
LOCAL_IS_HOST_MODULE:=
LOCAL_CC:=
LOCAL_CXX:=
LOCAL_CPP_EXTENSION:=
LOCAL_NO_DEFAULT_COMPILER_FLAGS:=
FDO: Only support locally The issues: - The size increase from utilizing FDO is quite large while utilizing runtime profiles in build. - By default, FDO is utilized globally if the target arch variant profiles exist. - Not all modules can show statistical significance in performance comparison, yet still suffer the size increase. The solution: - Only enable FDO locally with LOCAL_FDO_SUPPORT for modules which may benefit enough to justify the size tradeoff. Solution notes: - I've noted statistical significance in libwebcore and libskia thus far from utilizing FDO. - Analysis included sunspider, drawcanvas benchmarks, as well as gooda analysis on both arm and x86 - To support runtime profile generation in modules which have LOCAL_FDO_SUPPORT specified, BUILD_FDO_INSTRUMENTATION is still used. Otherwise, if the target arch variant profiles exist, FDO is utilized for specified modules. Change-Id: I7e95266943ff47c7d82b02e6200fd09911d0bb57
2013-08-14 08:41:52 +08:00
LOCAL_FDO_SUPPORT:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_ARM_MODE:=
LOCAL_YACCFLAGS:=
LOCAL_ASFLAGS:=
LOCAL_CFLAGS:=
LOCAL_CPPFLAGS:=
Add LOCAL_CLANG_*FLAGS for clang only flags. To be used only for some modules. Change-Id: I107ec37f11f738f860598f0c86c4ad7ec20c9011
2014-09-05 08:15:47 +08:00
LOCAL_CLANG_ASFLAGS:=
LOCAL_CLANG_CFLAGS:=
Add more support for GLOBAL_CONLYFLAGS. This will be necessary to support -std=gnu99 mode for clang 3.6, which defaults to C11 mode (unlike prior releases that use C99). Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
2014-11-26 16:53:46 +08:00
LOCAL_CLANG_CONLYFLAGS:=
Add LOCAL_CLANG_*FLAGS for clang only flags. To be used only for some modules. Change-Id: I107ec37f11f738f860598f0c86c4ad7ec20c9011
2014-09-05 08:15:47 +08:00
LOCAL_CLANG_CPPFLAGS:=
Add LOCAL_CONLYFLAGS. To pass compiler flags LOCAL_CFLAGS: to both C and C++ files; LOCAL_CONLYFLAGS: to only C files but not C++ files; LOCAL_CPPFLAGS: to only C++ file. LOCAL_CPPFLAGS and LOCAL_CONLYFLAGS can override flags in LOCAL_CFLAGS. Bug: 6967573 Change-Id: I88d9de0980e451b94bc7ae8c741ea2030eada3e1
2012-08-16 01:59:10 +08:00
LOCAL_CONLYFLAGS:=
Allow per module RTTI setting. This fixes a bug in previous check-ins. Change-Id: I5fcac192a7945720fd7667f7497078d310370bc5
2011-06-08 01:55:48 +08:00
LOCAL_RTTI_FLAG:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_C_INCLUDES:=
Build system support to export include paths Bug: 5573756 With this change, we can set LOCAL_EXPORT_C_INCLUDE_DIRS in the module definition to export include dir paths. Paths in LOCAL_EXPORT_C_INCLUDE_DIRS should be relative to the top dir of the source tree. If a library (shared or static) exports some include paths, any module using it will import the include paths and add them to the compiler command line. Change-Id: I49aabc589d2cf214044d13ccd5532ef68209adf0
2011-11-09 01:31:21 +08:00
LOCAL_EXPORT_C_INCLUDE_DIRS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_LDFLAGS:=
Add LOCAL_CLANG_*FLAGS for clang only flags. To be used only for some modules. Change-Id: I107ec37f11f738f860598f0c86c4ad7ec20c9011
2014-09-05 08:15:47 +08:00
LOCAL_CLANG_LDFLAGS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_LDLIBS:=
LOCAL_AAPT_FLAGS:=
LOCAL_AAPT_INCLUDE_ALL_RESOURCES Set this flag to include all the resources in the given dirs. Bug: 3313179 Change-Id: I68c02b24174bebe41a5948810cc2f49cc916e51c
2010-12-29 05:14:29 +08:00
LOCAL_AAPT_INCLUDE_ALL_RESOURCES:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_SYSTEM_SHARED_LIBRARIES:=none
LOCAL_PREBUILT_LIBS:=
LOCAL_PREBUILT_EXECUTABLES:=
LOCAL_PREBUILT_JAVA_LIBRARIES:=
LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES:=
add LOCAL_PREBUILT_STRIP_COMMENTS to clear_vars.mk
2009-08-07 12:50:51 +08:00
LOCAL_PREBUILT_STRIP_COMMENTS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_INTERMEDIATE_SOURCES:=
fix typo Change-Id: Ic00f82ea7bbe570ef30f52b353ba147664d755d7
2010-05-18 09:40:39 +08:00
LOCAL_INTERMEDIATE_SOURCE_DIR:=
Add support for LOCAL_JAVACFLAGS The Dalvik core libraries team would like to start making warnings errors in certain packages by definition LOCAL_JAVACFLAGS. This will allow easier debuging of warnings in other packages by supplying "-Xlint:..." options.
2010-02-02 03:13:32 +08:00
LOCAL_JAVACFLAGS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_JAVA_LIBRARIES:=
Add a tool to let you enforce layering between packages in a java module. And build system support for it too. Change-Id: I4dd5ed0b9edab6e8884b0d00cfeeae5fa38d967a
2011-10-31 12:37:35 +08:00
LOCAL_JAVA_LAYERS_FILE:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_NO_STANDARD_LIBRARIES:=
LOCAL_CLASSPATH:=
Compile using Jack. This allows to compile dex targeted java sources using Jack and Jill. Default is still to compile with the legacy toolchain. Default can be switched to the new toolchain by setting environement variable: export ANDROID_COMPILE_WITH_JACK=true Toolchain can also be forced for one module by defining LOCAL_USE_JACK:=true # false in the mk portion defining the module. Jack execution environement can be controlled with: Global variable ANDROID_JACK_VM allow to change the jvm executing Jack. Global variable ANDROID_JACK_VM_ARGS allows to change default args given to the jvm. Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args to give to Jack LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for the module. LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack. Change-Id: Ib81a0fd5f86a51d1e0edbb81cc791d828a05dd29
2014-09-08 20:45:14 +08:00
LOCAL_JACK_CLASSPATH:=
AI 145618: am: CL 145333 Cloned from CL 144759 by 'g4 patch'. Original change by joeo@abreu on 2009/04/06 19:54:13. Implement SDK add-ons in the build system. - Add an option to use the standard javadoc doclet instead of droiddoc, since droiddocs non-sdk templates aren't ready for prime time. - Add the notion of a stubs for a library. It's only implemented for java libraries, but when we do native libraries in the NDK or sdk-addons, it will work there too. Original author: joeo Merged from: //branches/cupcake/... Automated import of CL 145618
2009-04-10 10:31:12 +08:00
LOCAL_DROIDDOC_USE_STANDARD_DOCLET:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_DROIDDOC_SOURCE_PATH:=
LOCAL_DROIDDOC_TEMPLATE_DIR:=
LOCAL_DROIDDOC_CUSTOM_TEMPLATE_DIR:=
LOCAL_DROIDDOC_ASSET_DIR:=
LOCAL_DROIDDOC_CUSTOM_ASSET_DIR:=
LOCAL_DROIDDOC_OPTIONS:=
LOCAL_DROIDDOC_HTML_DIR:=
Add LOCAL_ADDITIONAL_HTML_DIR to clear_vars for devsite docs builds. Change-Id: Ib75e776d0220a86a08ddd5d7e09edd069af05da1
2013-02-09 07:45:45 +08:00
LOCAL_ADDITIONAL_HTML_DIR:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_ASSET_DIR:=
LOCAL_RESOURCE_DIR:=
LOCAL_JAVA_RESOURCE_DIRS:=
LOCAL_JAVA_RESOURCE_FILES:=
LOCAL_GENERATED_SOURCES:=
LOCAL_COPY_HEADERS_TO:=
LOCAL_COPY_HEADERS:=
LOCAL_FORCE_STATIC_EXECUTABLE:=
LOCAL_ADDITIONAL_DEPENDENCIES:=
LOCAL_STRIP_MODULE:=
Pack relocation tables for dynamic executables Add replocation-packer step for dynmic executables. Enable it by default for arm and arm64 platforms. Bug: http://b/18051137 Change-Id: I0c88fd31595bcea62a087f219acb9ecf9c80f2e5
2015-04-21 07:59:05 +08:00
LOCAL_PACK_MODULE_RELOCATIONS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_JNI_SHARED_LIBRARIES:=
Add LOCAL_JNI_SHARED_LIBRARIES_ABI build variable. LOCAL_JNI_SHARED_LIBRARIES_ABI allows individual APKs to specify specify the path where JNI shared libraries are stored in the APK. This is useful if you want to build an APK that supports a generic version of an ABI (e.g. armeabi) from a device configuration where TARGET_CPU_ABI is set to a more specific version of an ABI (e.g. armeabi-v7a.) Note that specifying the LOCAL_JNI_SHARED_LIBRARIES_ABI does not affect how the local JNI shared libraries are built. It just controls where the local JNI shared libraries are placed within the APK. Defaults to TARGET_CPU_ABI. Change-Id: I1cbb293e0c953688945fc147c7fc367421cf860b
2010-06-18 15:38:07 +08:00
LOCAL_JNI_SHARED_LIBRARIES_ABI:=
Support to extract JNI libs from prebuilt APK Use LOCAL_PREBUILT_JNI_LIBS to install prebuilt JNI libraries extracted from the prebuilt apk, or prebuilts as source, to the app specific lib path. LOCAL_PREBUILT_JNI_LIBS accepts 2 kinds of files: - Files like @path/to/libfoo.so (path inside the apk) are JNI libs extracted from the prebuilt apk. In this case, all embedded JNI libs inside the prebuilt apk are stripped. - Files like path/to/libfoo.so (path relative to LOCAL_PATH) are prebuilts in the source tree. Those prebuilt JNI libs are not defined as modules in the build system, so this works around possible module name conflict. Bug: 13170859 Change-Id: I91bb844cc11b3621a85733bc7e8910f168957ef0
2014-04-19 11:13:41 +08:00
LOCAL_PREBUILT_JNI_LIBS:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_JAR_MANIFEST:=
LOCAL_INSTRUMENTATION_FOR:=
Add LOCAL_APK_LIBRARIES argument. This allows you to build apks that link against other apks using the framework's new shared library apk feature. Also if you are using LOCAL_APK_LIBRARIES, then LOCAL_DEX_PREOPT will not be allowed. This is because using preopt means the apk is stripped of its dex file, so the pre-installed apk can't be redexed if its associated library changes. (Even if the build system didn't strip the dex, Dalvik still has issues because it assumes a pre-odex file is always valid.) Change-Id: I952c0d24f8975f75aff67f78b5faeec91144c3e7
2013-03-12 09:04:55 +08:00
LOCAL_APK_LIBRARIES:=
Temporarily use a separate var for including shared resources Change-Id: I56636a1d7dfdaa070706f1991f80e03fe2f71069
2014-03-26 06:45:34 +08:00
LOCAL_RES_LIBRARIES:=
Fix inherited dependency when instrmentation. It turns out we should also LOCAL_INSTRUMENTATION_FOR. To disambiguate LOCAL_INSTRUMENTATION_FOR_PACKAGE_NAME is renamed to LOCAL_MANIFEST_INSTRUMENTATION_FOR. Bug: 2902591 Change-Id: I6cb893c135736fc4170aa2259105b4c5eea798a1
2010-09-03 06:41:01 +08:00
LOCAL_MANIFEST_INSTRUMENTATION_FOR:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_AIDL_INCLUDES:=
LOCAL_JARJAR_RULES:=
LOCAL_ADDITIONAL_JAVA_DIR:=
LOCAL_ALLOW_UNDEFINED_SYMBOLS:=
Remove support of disabling Jack. We removed code and variables related to running dx on classes.jar in this change. Also removed target emma rules (but kept the emma rules for host java libraries), for it's now done by Jack. We still support to build classes.jar (and javalib.jar for static Java libraries) using javac, because tools like javadoc need class files as input. Removed the obsolete install-dex-debug. Bug: 27400061 Change-Id: If0bcdfe62cb181a98754fb0dbe1c12c92e38d3e8
2016-03-29 09:39:42 +08:00
# full or incremental
LOCAL_JACK_ENABLED:=full
Compile using Jack. This allows to compile dex targeted java sources using Jack and Jill. Default is still to compile with the legacy toolchain. Default can be switched to the new toolchain by setting environement variable: export ANDROID_COMPILE_WITH_JACK=true Toolchain can also be forced for one module by defining LOCAL_USE_JACK:=true # false in the mk portion defining the module. Jack execution environement can be controlled with: Global variable ANDROID_JACK_VM allow to change the jvm executing Jack. Global variable ANDROID_JACK_VM_ARGS allows to change default args given to the jvm. Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args to give to Jack LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for the module. LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack. Change-Id: Ib81a0fd5f86a51d1e0edbb81cc791d828a05dd29
2014-09-08 20:45:14 +08:00
LOCAL_JACK_FLAGS:=
Update code coverage filtering Replaces old LOCAL_EMMA_COVERAGE_FILTER by new variables: - LOCAL_JACK_COVERAGE_INCLUDE_FILTER for included classes - LOCAL_JACK_COVERAGE_EXCLUDE_FILTER for excluded classes Both variables can contain a comma-separated list of class names, where * and ? are accepted wildcard (like foo.?ar.*). When code coverage is enabled, we will use these variables to pass code coverage filters on the Jack command-line. Bug: 28014424 Change-Id: Ic29c99b6feb7ea2251c29d659e7ea1f1c46d1ed1
2016-04-07 00:18:47 +08:00
LOCAL_JACK_COVERAGE_INCLUDE_FILTER:=
LOCAL_JACK_COVERAGE_EXCLUDE_FILTER:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
LOCAL_CERTIFICATE:=
LOCAL_SDK_VERSION:=
Allow to force min sdk given to Jack Allows setting the min sdk version for target Jack commands, overriding the default value obtained from LOCAL_SDK_CURRENT. Bug: 28188420 Change-Id: I1b84ad8a7b6ae30639f8ade455c1e542af5692e4
2016-04-15 03:51:46 +08:00
LOCAL_MIN_SDK_VERSION:=
New LOCAL_SDK_RES_VERSION config var. This allows an app to target a different SDK level for its resources than it uses for its Java code. This is useful because it is generally safe to use various newer symbols like attribute names, as older versions of the platform will simply ignore them. Change-Id: Ida19ec9f259c4ea70de846e9a63546e263b1c91e
2011-09-19 08:34:29 +08:00
LOCAL_SDK_RES_VERSION:=
Support stl variants when LOCAL_NDK_VERSION is set. LOCAL_NDK_STL_VARIANT can be set to system, stlport_static, stlport_shared or gnustl_static. It defaults to system. Change-Id: I2840d30ff732a00bc0ea70eab8a8179aea0abbdf
2011-03-04 10:53:53 +08:00
LOCAL_NDK_STL_VARIANT:=
Support EMMA_INSTRUMENT in both full and unbundled builds. Bug: 6987838 - With this change, use "EMMA_INSTRUMENT=true" to enable emma in full or unbundled build. - You don't need to add "LOCAL_STATIC_JAVA_LIBRARIES += emma" any more for unbundled apps. - Now a single var LOCAL_EMMA_INSTRUMENT replaces the previous LOCAL_NO_EMMA_INSTRUMENT and LOCAL_NO_EMMA_COMPILE. - By default, if EMMA_INSTRUMENT is true, emma is enabled for only non-test apps. - A new global var EMMA_INSTRUMENT_STATIC. It enables EMMA_INSTRUMENT and builds emma into apk/jar as static library, instead of using emma as part of shared library core.jar. Change-Id: I0aa219e83074879ececc159b5b07c39eb07ccc00
2012-08-22 07:59:01 +08:00
LOCAL_EMMA_INSTRUMENT:=
Make it easier to enable obfuscation and optimization. With this change, use: * LOCAL_PROGUARD_ENABLED := obfuscation # to enable obfuscation * LOCAL_PROGUARD_ENABLED := optimization # to enable optimization * LOCAL_PROGUARD_ENABLED := obfuscation optimization # to enable both Now the meaning of the LOCAL_PROGUARD_ENABLED options: * full: Use the build system's default configurations: with shrink but no obfuscation or optimization, global proguard flags in build/core/proguard.flags are applied. * custom: The same as "full" except no aapt-generated resource-related proguard flags. * nosystem: Don't use any build system's default configurations; but aapt-generated proguard flags are still applied. You are responsible for any other flags. * disabled: Disable proguard. * obfuscation: The same as "full" but with obfuscation enabled. * optimization: The same as "full" but with optimization enabled. * no value (the default): The build system chooses the proper value: "full" if it's an app; "disabled" if it's a library. You can use more than 1 of them in a meaningful combination, for example: LOCAL_PROGUARD_ENABLED := obfuscation optimization Bug: 10307372 Change-Id: Id248caca3048e99547f16559fae74f4afe85c354
2013-08-22 09:32:49 +08:00
LOCAL_PROGUARD_ENABLED:= # '',full,custom,nosystem,disabled,obfuscation,optimization
Add the ability to turn on proguard for java targets, and to call aapt to generate a rules file for proguard for stuff from the manifest and other resources that need to be kept.
2009-08-31 04:39:24 +08:00
LOCAL_PROGUARD_FLAGS:=
Compile using Jack. This allows to compile dex targeted java sources using Jack and Jill. Default is still to compile with the legacy toolchain. Default can be switched to the new toolchain by setting environement variable: export ANDROID_COMPILE_WITH_JACK=true Toolchain can also be forced for one module by defining LOCAL_USE_JACK:=true # false in the mk portion defining the module. Jack execution environement can be controlled with: Global variable ANDROID_JACK_VM allow to change the jvm executing Jack. Global variable ANDROID_JACK_VM_ARGS allows to change default args given to the jvm. Global variable ANDROID_JACK_EXTRA_ARGS allows to define some default args to give to Jack LOCAL_JACK_VM_ARGS allows to override default args given to the jvm for the module. LOCAL_JACK_EXTRA_ARGS allows to override default args passed to Jack. Change-Id: Ib81a0fd5f86a51d1e0edbb81cc791d828a05dd29
2014-09-08 20:45:14 +08:00
LOCAL_JACK_PROGUARD_FLAGS:=
Separate out Proguard flag files to fix dependency. Bug: 3048005 Change-Id: I3e77ca1082cf7c92a43b249e5c887e3fbdf4ba11
2010-09-30 05:50:41 +08:00
LOCAL_PROGUARD_FLAG_FILES:=
resolved conflicts for merge of 4df82b3e to klp-dev-plus-aosp Change-Id: I7a1d9e1954ede06a818814bd05a77c69f1ed3bc6
2014-02-09 02:31:36 +08:00
LOCAL_TEST_MODULE_TO_PROGUARD_WITH:=
enhancement for building app with emma code coverage * global filter to avoid applying instrumentation on emma classes * remove local variable information at dex step instead of compile time Change-Id: If04c27bc717f34816077a98ead9ceb0dbcbb0d2f
2010-03-11 07:48:03 +08:00
LOCAL_EMMA_COVERAGE_FILTER:=
Allow explicit warnings for projects Enabled compiler warnings by default and then modified javac command to include warnings only if a project's warning flag, LOCAL_WARNINGS_ENABLE, is set to true. Change-Id: I5111d16a862f3afaaf1dcba2f2c2b7fc072613f1
2010-07-08 02:42:19 +08:00
LOCAL_WARNINGS_ENABLE:=
Allow packages to place manifest files in any directory via a new definition LOCAL_ABS_MANIFEST_FILE. The existing LOCAL_MANIFEST_FILE variable will also be supported. (Necessary if manifests are being programmatically generated in the intermediates directory) Change-Id: I77a8eb1b8040b966b944464281d00c161ff34d3c
2012-04-13 01:20:53 +08:00
LOCAL_FULL_MANIFEST_FILE:=
Packages can specify where to find AndroidManifest.xml By overriding LOCAL_MANIFEST_FILE, a package can now specify which AndroidManifest.xml file to use. This also allows for AndroidManifest.xml to be in a non-standard location, though that's not recommended. Change-Id: Ib6d1baeef7601e5a93d4ce64d18883d45373fc12
2010-07-24 02:03:29 +08:00
LOCAL_MANIFEST_FILE:=
Set up rules to merge AndroidManifest.xmls Now you can merge the library manifest files to the main app's AndroidManifest.xml with LOCAL_FULL_LIBS_MANIFEST_FILES. LOCAL_FULL_LIBS_MANIFEST_FILES is a list of paths relative to the top of the source tree. Bug: 12907528 Change-Id: I16a347c83dfb6fbbb7d5d40284b7c65aa682fdd2
2014-02-06 10:24:45 +08:00
LOCAL_FULL_LIBS_MANIFEST_FILES:=
Now slang supports "-I" options. Change-Id: I32aef6c913d9d30f9982a593397145f1562aecf9
2010-09-02 04:28:52 +08:00
LOCAL_RENDERSCRIPT_INCLUDES:=
Provide mechanism to override llvm-rs-cc headers. Change-Id: I87fd496069a9dfde633e2d232e436fa5d7315cc0
2011-08-24 13:01:49 +08:00
LOCAL_RENDERSCRIPT_INCLUDES_OVERRIDE:=
Support custom RenderScript compiler Change-Id: I85e38e84565e04f99dd26217f280274883dc322d
2011-05-26 08:16:22 +08:00
LOCAL_RENDERSCRIPT_CC:=
Build rules for Renderscript compatibility library. Bug: 7419958 Change-Id: I2e0f0bb632e6ff22b2cf1a1b96b28364637995cc
2012-11-29 08:52:41 +08:00
LOCAL_RENDERSCRIPT_COMPATIBILITY:=
Enable -Wall/-Werror with LOCAL_RENDERSCRIPT_FLAGS. Change-Id: Ia2a058e6711839d89072c2e96f0c60aa4cedda6b
2011-12-07 10:43:24 +08:00
LOCAL_RENDERSCRIPT_FLAGS:=
Provide LOCAL_RENDERSCRIPT_TARGET_API override. BUG=5206223 This allows us to set the RS API level independent of the other SDK versions that a developer might choose. Change-Id: Id8b476abcbbbdaa86e04ba0ea16414cb2fa5bd15
2011-08-30 09:53:53 +08:00
LOCAL_RENDERSCRIPT_TARGET_API:=
new LOCAL_DEX_PREOPT option "nostripping" Set "LOCAL_DEX_PREOPT := nostripping" to do dex-preopt while not strip the classes.dex. Bug: 5396625 5502338 Change-Id: Ie8dea4414ebeefeae89c6433b246faea27baa5e7
2011-10-25 03:17:03 +08:00
LOCAL_DEX_PREOPT:= # '',true,false,nostripping
Multilib support for odex If the VM is libart and DEXPREOPT is enabled, - For a Java library and the boot image, we build for both 1st arch and 2nd arch. - For an app, we build for the multilib arch the module is targeted for. The odex file will be in <arch_name>/<module_name>.odex inside the same dir where the jar/apk file gets installed. Nothing changed if it's built for libdvm. Bug: 14694978 Change-Id: I45118a83758b41d52d6c9e38f93f0ba2775a6c74
2014-05-14 04:57:28 +08:00
LOCAL_DEX_PREOPT_IMAGE_LOCATION:=
Introduce per-product per-module dex-preopt config - Added LOCAL_DEX_PREOPT_FLAGS to pass extra flags to dex2oat. - Added macro add-product-dex-preopt-module-config to specify almost arbitrary dex-preopt config/flags to modules in product configuration: $(call \ add-product-dex-preopt-module-config,<module_name_list>,<config_or_flags>) How <config_or_flags> is interpreted is decided by dex_preopt_odex_install.mk and dex2oat. For now if it's "disable" we disable dexpreopt for the given modules; otherwise pass it to dex2oat as command line flags. - If there are multiple configs for the same module in the product inheritance, the first takes precedence. - Added PRODUCT_DEX_PREOPT_DEFAULT_FLAGS so you can specify default dex2oat flags in product configuration. - Added PRODUCT_DEX_PREOPT_BOOT_FLAGS to specify flags of building boot.oat. Bug: 17791867 Change-Id: I1b2955e8e51039e94d1ff43a3265a8d03598632c
2014-10-08 09:07:23 +08:00
LOCAL_DEX_PREOPT_FLAGS:=
Add support for PB_ENABLE_MALLOC in nanopb-c There will be two version of the the nanopb-c library, libnanopb-c-2.8.0 which doesn't support automatic malloc and libnanopb-c-2.8.0-enable_malloc which does. There will be two version of the the nanopb-c library, libnanopb-c-2.8.0 which doesn't support automatic malloc and libnanopb-c-2.8.0-enable_malloc which does. Set LOCAL_PROTO_OPTIMIZE_TYPE=nanopb-c which doesn't support malloc and set it to nanopb-c-enable_malloc which does. For client code details see nanopb-api: http://koti.kapsi.fi/jpa/nanopb/docs/reference.html Change-Id: If238412463aabb5e1d556dfc9c464bcaf9e3333a
2014-06-26 10:48:51 +08:00
LOCAL_PROTOC_OPTIMIZE_TYPE:= # lite(default),micro,nano,full,nanopb-c,nanopb-c-enable_malloc
Allow module-specific protoc flags. You can add local protoc flags via LOCAL_PROTOC_FLAGS. Change-Id: If246a4edafe1edcec6a7f193bde8ce3c83de745b
2010-11-06 02:30:58 +08:00
LOCAL_PROTOC_FLAGS:=
Allow proto builds to pass in java proto params. Change-Id: I65fe0cd96f818f59267da6159e6bd2ad28f07a11
2013-07-26 03:28:19 +08:00
LOCAL_PROTO_JAVA_OUTPUT_PARAMS:=
Build system tweaks for Valgrind. Added LOCAL_NO_CRT to enable building executables that do not link to the C runtime library. Removed support for LOCAL_MODULE_SUBDIR since it was broken and unused. (Was going to use it but ended up using LOCAL_MODULE_PATH instead.) Change-Id: I3b6f5ab7e5ae6aaa7119899adccece2b4ab1cbb3
2011-02-05 12:15:00 +08:00
LOCAL_NO_CRT:=
Add LOCAL_NO_LIBGCC. This can be used to compile independent libraries without the need for libgcc.a. Change-Id: I924200995569d9a978ddbaa6ec321d80734f1374
2015-07-03 02:05:27 +08:00
LOCAL_NO_LIBGCC:=
Install path support for vendor modules. Bug: 5284764 Set "LOCAL_PROPRIETARY_MODULE := true" to install module to vendor partition. Change-Id: I1301acc10664a12e313f3b868d9fd6400ac8b133
2011-09-14 04:57:26 +08:00
LOCAL_PROPRIETARY_MODULE:=
Set up rules to build oem.img To build oem.img: - You must define BOARD_OEMIMAGE_PARTITION_SIZE in your BoardConfig.mk - The file system type will be the same as system.img and userdata.img. - To install a module to oem.img, use "LOCAL_OEM_MODULE := true" - run "make -j48 showcommands oem_image dist". By default it's not built. Bug: 13367676 Change-Id: I1a26d4d0c61b72ecffe60279667b1b3de050780d
2014-03-12 08:13:27 +08:00
LOCAL_OEM_MODULE:=
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
2015-03-13 09:30:39 +08:00
LOCAL_ODM_MODULE:=
Install to TARGET_OUT_APPS_PRIVILEGED if LOCAL_PRIVILEGED_MODULE is true Change-Id: I268b8652f18034aa3fdd3126ebf6196f78c4bbb2
2013-05-09 06:49:08 +08:00
LOCAL_PRIVILEGED_MODULE:=
Restrict vendor modules to help AOSP product distribution. Bug: 5692177 If you set "PRODUCT_RESTRICT_VENDOR_FILES := true" in a product configuration, this changes restricts that: - No overlays in the vendor tree. - No PRODUCT_COPY_FILES coming from the vendor tree. - Any referenced package with Android.mk in the vendor tree must have LOCAL_MODULE_OWNER set to a value that's compared against a whitelist stored in the core build system. Change-Id: I172b84c7c853e9a04bf9879ea8dec90bd5054230
2011-12-10 07:11:57 +08:00
LOCAL_MODULE_OWNER:=
Build Support for CTS Native Tests Bug 4970300 Adds two new variables, CTS_TEST_CASES and CTS_TEST_XMLS, to be read from CtsTestCaseList.mk. The CTS_TEST_CASES variable can be used to copy any sort of file to the repository/testcases CTS directory. The CTS_TEST_XMLS variable can be used to inject test package xmls from any source rather than relying upon the monolithic and mostly serial buildCts.py script. The existing CTS_CORE_CASE_LIST is coded to only support APKs, so it could not be retrofitted to support native tests. However, the two new variables can do even more than CTS_CORE_CASE_LIST due to their generality. In the future, the idea is move away from CTS_CORE_CASE_LIST and also generate XMLs using separate tools rather than just buildCts.py. Change-Id: Ib52722861c37e0f4d511f9041928395bcaba5dea
2011-12-13 15:54:49 +08:00
LOCAL_CTS_TEST_PACKAGE:=
Adding clean variables for some variables used in CTS. 1. A CTS package can specify the test runner used to launch its tests from the device. This is useful for preparing and cleaning the device through some shell commands if necessary. bug:5946699 Change-Id: Ib1d6454c4274b1c37323235c9b3a195f3b9d8131
2012-03-13 07:49:58 +08:00
LOCAL_CTS_TEST_RUNNER:=
Add LOCAL_CLANG variable to switch C/C++ build environment to Clang. Change-Id: I8ca1c24f51aa5546ac9618d31566a52e4fdb1436 Conflicts: core/clear_vars.mk
2012-03-20 22:00:16 +08:00
LOCAL_CLANG:=
More flexibility to keep/remove R.class in static Java library - Usually you don't need to set LOCAL_JAR_EXCLUDE_FILES in your Android.mk, if your static library is directly used by an app. - If your library will be included by another library that need reference the R/Manifest class, you can set LOCAL_JAR_EXCLUDE_FILES := none to keep the generated classes. - If your library includes another static library that has Android resource and you want to remove the generated classes carried by the static library, set: LOCAL_JAR_EXCLUDE_FILES := $(ANDROID_RESOURCE_GENERATED_CLASSES) With the LOCAL_JAR_EXCLUDE_FILES value "none", deprecate the old long variable LOCAL_KEEP_R_CLASS_IN_STATIC_JAVA_LIBRARY. Change-Id: I3b9ad5d66f0262f784feb09bc1537c5b01256258
2012-06-20 01:40:37 +08:00
LOCAL_JAR_EXCLUDE_FILES:=
Split framework jar. Change-Id: I38c68ac169a4ea10e4640b5d8e24298a6caaf441
2013-07-18 11:29:51 +08:00
LOCAL_JAR_PACKAGES:=
Support more precise package exclusion from JAR files. Allow LOCAL_JAR_PACKAGES to work on subpackages. Previously it only worked on top-level packages due to a bug in how the directories were recursively deleted. Add LOCAL_JAR_EXCLUDE_PACKAGES to allow specific subpackages to be excluded. This rule applies after LOCAL_JAR_PACKAGES has selected which packages to include. It may also be used independently. Change-Id: Ibd0e495be1a20c84b59c9da132e92100ef3f8705
2014-05-24 09:41:19 +08:00
LOCAL_JAR_EXCLUDE_PACKAGES:=
Add LOCAL_SOURCE_FILES_ALL_GENERATED support Set "LOCAL_SOURCE_FILES_ALL_GENERATED := true" if you want to build a Java library from only generated source files, without any static source files. Previously this is not allowed. This is needed by building api stub libraries, which have only source files of generated stub files. Bug: 6814443 Change-Id: Idb2ae9c71a473b796154a03ef07a3403461c4f3c
2012-07-20 05:38:43 +08:00
LOCAL_SOURCE_FILES_ALL_GENERATED:= # '',true
Add LOCAL_DONT_DELETE_JAR_META_INF To support to not delete META_INF directory from the static Java libraries. Change-Id: I720bfa059c43dd457a74a0c60bb6797aa408ecaf
2012-08-31 03:59:42 +08:00
# Don't delete the META_INF dir when merging static Java libraries.
LOCAL_DONT_DELETE_JAR_META_INF:=
Additional certificates support for an apk. Change-Id: I5b35d5728ba9d65f7ece956127270a9ca2ea0efe
2012-11-14 02:55:28 +08:00
LOCAL_ADDITIONAL_CERTIFICATES:=
Build from source or prebuilt With this change, you can easily switch between building from source code and prebuilt. Set LOCAL_PREBUILT_MODULE_FILE to the path of the prebuilt file, relative to the top of the source tree, in the usual module definition. The prebuilt will be used unless any of the followings satisfied: 1) ANDROID_BUILD_FROM_SOURCE is "true", which disable prebuilt globally; 2) The module name is in ANDROID_NO_PREBUILT_MODULES; 3) The LOCAL_PATH is prefixed by any of ANDROID_NO_PREBUILT_PATHS. A developer can set ANDROID_NO_PREBUILT_MODULES or ANDROID_NO_PREBUILT_PATHS to build only his own module(s) from source, while build other modules from prebuilts. You can set ANDROID_BUILD_FROM_SOURCE to true to build everything from source. Those variables can be set with shell environmental variable or in your buildspec.mk. Sometimes module B is able to be built from source only if module A is also built from source, for example, if B is the test apk of A. In that case, you can use the macro include-if-build-from-source to include B's Android.mk only if A is built from source too, or if-build-from-source to conditionally include the definition of module B, if their module definitions are in the same Android.mk. Support host-executable-hook and host-shared-library-hook. Change-Id: Icab7cf028c87eaba0dd7efc2a7749fd6f32b44e4
2012-12-14 10:23:01 +08:00
LOCAL_PREBUILT_MODULE_FILE:=
Add LOCAL_POST_LINK_CMD. For now we support LOCAL_POST_LINK_CMD only for static executables. This fixed the hack of building linker which need to insert additional step after link. Bug: 17403674 Change-Id: Iefdfe1e3fab3a30c5d4ad701d46f931481eab572
2014-09-06 06:46:43 +08:00
LOCAL_POST_LINK_CMD:=
Add LOCAL_POST_INSTALL_CMD With this support, you can piggy-back some symlinks when a module gets installed. This is especially helpful if the target of the symlink doesn't exist on the build machine. Change-Id: I48af7a90ce67475bc49b72f94a8753b94da98edd
2013-02-07 03:44:41 +08:00
LOCAL_POST_INSTALL_CMD:=
Support for LOCAL_HAL_STATIC_LIBRARIES Now you can have a board config variable BOARD_HAL_STATIC_LIBRARIES, which is a list of board-specific HAL static library names with pattern "lib<library_name>.<board_specific_suffix>". LOCAL_HAL_STATIC_LIBRARIES is a list of "lib<library_name>" and any matched BOARD_HAL_STATIC_LIBRARIES will be added to the LOCAL_STATIC_LIBRARIES; if no match is found, lib<library_name>.default will be used. Bug: 10262105 Change-Id: Ic89d8d417d1dd65a227e4187a157fd3b77c4af34
2013-08-14 03:35:10 +08:00
LOCAL_HAL_STATIC_LIBRARIES:=
Support to optionally run rmtypedefs. Bug: 10330586 Change-Id: I6ddfca2ec986cf2c82b0942b7a5360508f095e9a
2013-08-15 07:59:00 +08:00
LOCAL_RMTYPEDEFS:=
Add "WITH_SYNTAX_CHECK=1 make ..." The new option WITH_SYNTAX_CHECK=1 instructs build system to invoke "clang -fsyntax-only" to utilize clang's better diagnostics before calling LOCAL_CC/LOCAL_CXX for code generation. The compilation time is slightly longer, and the generated object file should be the same as w/o WITH_SYNTAX_CHECK Project use lots of GCC extensions (eg. nested function) not supported by clang may opt out by adding LOCAL_NO_SYNTAX_CHECK:=true Change-Id: Iaeedd07d5719f9df9675ab57e307e28a9c855c1b
2013-08-27 17:55:46 +08:00
LOCAL_NO_SYNTAX_CHECK:=
Add "WITH_STATIC_ANALYZER=1 m/mm/mmm/mma/mmma ..." The new option WITH_STATIC_ANALYZER=1 instructs build system to run static analyzer via "clang --analyze" on a successful build. If analyzer finds any issue, instruction to open report is displayed. See http://clang-analyzer.llvm.org/scan-build.html for details. WITH_STATIC_ANALYZER trumps WITH_SYNTAX_CHECK if both exist. Project use lots of GCC extensions (eg. nested function) not supported by clang may opt out by adding LOCAL_NO_STATIC_ANALYZER:=true Change-Id: I9970560560bd52ce5f0fd7129c3488629627c735
2013-09-10 17:37:14 +08:00
LOCAL_NO_STATIC_ANALYZER:=
Call clang-tidy based on WITH_TIDY* variables. * Call clang-tidy before every C/C++ compilation if (1) clang-tidy is found at $(PATH_TO_CLANG_TIDY) (2) $(my_clang) is true (3) LOCAL_TIDY is 1 or true, or LOCAL_TIDY is undefined and WITH_TIDY is 1 or true. * clang-tidy is called with -checks=$(my_tidy_checks), which has default '-*,google*,-google-readability*' and can be overwritten by WITH_TIDY_CHECKS. * LOCAL_TIDY_CHECKS is appended to $(my_tidy_checks) * Extra flags are passed to clang-tidy through WITH_TIDY_FLAGS or LOCAL_TIDY_FLAGS. * To quickly find and fix clang-tidy warnings, set $(WITH_TIDY_ONLY) to 1 or true to skip compilation of C/C++ files. * Add a PHONY tidy_only target, which includes all $(cpp_objects) and $(c_objects). * The 'mm' and 'mmm' functions are changed to call make with the 'tidy_only' target when WITH_TIDY_ONLY is true or 1. In that case, only clang-tidy is called for C and C++ files. Bug: http://b/27779618 Change-Id: I8adcfff217d68af49849b79aacee7d7654cafb1b
2016-04-01 07:30:23 +08:00
LOCAL_TIDY:=
LOCAL_TIDY_CHECKS:=
LOCAL_TIDY_FLAGS:=
build: rename LOCAL_32BIT_ONLY to LOCAL_32_BIT_ONLY Rename for consistency with TARGET_IS_64_BIT. Change-Id: I824dcaed0c1e88b8246bcffb21ab3f1772175926
2014-01-30 10:20:01 +08:00
LOCAL_32_BIT_ONLY:= # '',true
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_MULTILIB:=
add support for module supported or unsupported target architectures Add four new variables for module makefiles: LOCAL_MODULE_TARGET_ARCH specifies that a module is only supported for one or more architectures. Any architecture not in the list will be not attempt to build the module. The expected use case is prebuilts that are only suitable for a single architecture, or modules like llvm that need per-architecture support. LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH specifies that a module cannot be built for one or more architectures. LOCAL_MODULE_TARGET_ARCH_WARN and LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN are the same, but warn that the arch is not supported, which is useful for modules that are critical but not yet working. The logic for whether or not to build an architecture is fairly complicated, so this patch consolidates it into module_arch_supported.mk Change-Id: I120caf4a375f484e1fd6017b60c2f53882ae01e6
2014-02-07 06:45:37 +08:00
LOCAL_MODULE_TARGET_ARCH:=
LOCAL_MODULE_TARGET_ARCH_WARN:=
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH:=
LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN:=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_MODULE_HOST_ARCH:=
Add HOST_CROSS_OS Instead of using recursive make to change the HOST_OS when building the windows SDK under linux, add the concept of cross-building to another host os. Bug: 23566667 Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
2015-08-15 03:59:50 +08:00
LOCAL_MODULE_HOST_ARCH_WARN:=
LOCAL_MODULE_UNSUPPORTED_HOST_ARCH:=
LOCAL_MODULE_UNSUPPORTED_HOST_ARCH_WARN:=
LOCAL_MODULE_HOST_CROSS_ARCH:=
LOCAL_MODULE_HOST_CROSS_ARCH_WARN:=
LOCAL_MODULE_UNSUPPORTED_HOST_CROSS_ARCH:=
LOCAL_MODULE_UNSUPPORTED_HOST_CROSS_ARCH_WARN:=
Add LOCAL_NO_FPIE. Not all executables should be built with -pie. bug 15814177 Change-Id: I402e8a531866b507ee80a0bf677f9f3551ca7693
2014-09-04 06:01:46 +08:00
LOCAL_NO_FPIE :=
Move selection of C++ STL into the build system. Preparing for migration from stlport to libc++. STL selection is done with LOCAL_CXX_STL (valid values are default, none, libc++, libc++_static, stlport, stlport_static, bionic). The selection of the STL is as follows: if LOCAL_CXX_STL == 'default' ifdef LOCAL_SDK_VERSION Use whatever STL the other NDK options have selected. else Use bionic's libstdc++ for target, GNU libstdc++ for host. This is compatible with the existing build options. endif else if LOCAL_CXX_STL == 'stlport' Use stlport. else if LOCAL_CXX_STL == 'libc++' Use libc++. else if LOCAL_CXX_STL == '' Don't use any STL. endif endif Bug: 15193147 Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
2014-09-13 05:46:57 +08:00
LOCAL_CXX_STL := default
Add option for generating coverage info. To enable building with coverage, the environment variable NATIVE_COVERAGE must be set to true. Set `LOCAL_NATIVE_COVERAGE := true` to generate coverage information for a given component. This is currently not supported for clang (b/17574078, b/17583330). If static library A is included in a binary B (dynamic or static executable, or shared library), and A is built with coverage information, B is required to link with libgcov.a. Since the make does not offer a good way to track this dependency, link libgcov.a even if LOCAL_NATIVE_COVERAGE is not set (but still guarded by NATIVE_COVERAGE). This ensures that all of the libgcov dependencies will always be resolved, and causes no change in the resulting binary if coverage is not used. Bug: 10134489 Change-Id: Id5a19f2c215e4be80e6eae27ecc19b582f2f6813
2014-09-20 05:25:57 +08:00
LOCAL_NATIVE_COVERAGE :=
Support prebuilt apk source selection based on PRODUCT_AAPT_PREF_CONFIG Two new LOCAL variables are added to support dpi-specific prebuilt apk selection: - LOCAL_DPI_VARIANTS: specify a list of dpis the module provides with specific prebuilt. Example: LOCAL_DPI_VARIANTS := xxhdpi xhdpi hdpi mdpi - LOCAL_DPI_FILE_STEM: specify the dpi-specific source file name pattern. Example: LOCAL_DPI_FILE_STEM := MyApp-%.apk "%" will be substitued by $(PRODUCT_AAPT_PREF_CONFIG) in the core build system. If you don't set up LOCAL_DPI_FILE_STEM, the default is $(LOCAL_MODULE)_%.apk. The build system searches $(PRODUCT_AAPT_PREF_CONFIG) in a prebuilt apk module's $(LOCAL_DPI_VARIANTS). If not found, use whatever $(LOCAL_SRC_FILES) as the source file; Otherwise use $(LOCAL_DPI_FILE_STEM) to construct the dpi-specific apk's source file name, and use whatever directory name of $(LOCAL_SRC_FILES). Bug: 18388705 Change-Id: I63cae73f1b6f880302142abc476b3ce1fb5500b5
2014-11-18 08:56:04 +08:00
LOCAL_DPI_VARIANTS:=
LOCAL_DPI_FILE_STEM:=
Add support for ubsan. Rather than adding LOCAL_UB_SANITIZER, LOCAL_THREAD_SANITIZER, etc for each new sanitizer, deprecate LOCAL_ADDRESS_SANITIZER in favor of LOCAL_SANITZE that mirrors the behavior of -fsanitize=<sanitizers>. For example, the following will use both asan and ubsan: LOCAL_SANITIZE := address undefined We'll leave LOCAL_ADDRESS_SANITIZER around for compatibility until we can clean up the tree. Change-Id: I8a62315129d4753f8e992584ca6db1e5dfdd4d2a
2014-12-12 10:56:26 +08:00
LOCAL_SANITIZE:=
Add LOCAL_SANITIZE_RECOVER. This is needed for projects that have known ubsan issues that we can't fix right away (perhaps because it's an upstream project that we're diligent about keeping in sync with upsteam). Also make the normal ubsan use -fno-sanitize-recover=all by default. Change-Id: I1b0f3309792f32dbd08c18816d7306e76c8d7c30
2015-04-17 09:08:44 +08:00
LOCAL_SANITIZE_RECOVER:=
Add LOCAL_NOSANITIZE. This can be used to selectively disable individual sanitizers on a target. For example, some parts of libc should be built with SafeStack (when requested with SANITIZE_TARGET), but never with AddressSanitizer. Current build rules specify LOCAL_SANITIZE := never to disable AddressSanitizer; the idea is to change that to LOCAL_NOSANITIZE := address thread. Bug: 27729263 Change-Id: I2b770f2ce3faf6ad6798792327e96adb86fe4a4f
2016-05-13 04:07:17 +08:00
LOCAL_NOSANITIZE:=
Generate DBus proxies and adaptors separately Enable daemons exposing an interface over DBus to easily build client libraries. Now daemons can write rules like: include $(CLEAR_VARS) LOCAL_MODULE := libdbus-binding-example-client LOCAL_DBUS_PROXY_PREFIX := dbus-example-example LOCAL_SRC_FILES := \ dbus_bindings/org.chromium.Example.Manager.dbus.xml \ dbus_bindings/dbus-service-config.json include $(BUILD_SHARED_LIBRARY) to expose a client library. While here, add support for generating independent adaptor header files on a per interface basis. Bug: 22608897 Change-Id: I011f9afc234811c31e445898321c2731c482fa77
2015-08-15 05:55:32 +08:00
LOCAL_DBUS_PROXY_PREFIX:=
Support LOCAL_INIT_RC. A module can install a companion init.rc file, by specifying: LOCAL_INIT_RC := <init.rc-file-path-replative-to-LOCAL_PATH> You can also use the variant with _32 or _64 suffix. Bug: 23186545 Change-Id: I00a96509f5707ae39361a0c5555fa59d46c90322
2015-08-21 03:02:10 +08:00
LOCAL_INIT_RC:=
Add support for LOCAL_MODULE_SYMLINKS Specifying LOCAL_MODULE_SYMLINKS will create symlinks to the installed module in the same directory. Change-Id: Idecb2b75f0c9999eb000eed9a79a989244ccf6c2
2016-07-15 07:02:57 +08:00
LOCAL_MODULE_SYMLINKS:=
Add LOCAL_MODULE_HOST_OS Instead of wrapping a host module definition in 'ifeq($(HOST_OS),...)' in the Android.mk files, define which hosts are supported using LOCAL_MODULE_HOST_OS. A blank LOCAL_MODULE_HOST_OS means that linux and darwin are supported. A non-empty LOCAL_MODULE_HOST_OS lists the supported HOST_OSs. Change-Id: I1e342d1908cfa00aef2c39c145b4f5f81c373bc6
2015-08-15 03:59:06 +08:00
LOCAL_MODULE_HOST_OS:=
Allow modules to override the default NOTICE file. It's useful in projects where different top level modules have different licenses associated with them. (cherry picked from commit 3026f4daf11b2d4729559d49624e748a82f15495) Change-Id: I71b20d6f979c0f50562f4f44b2af1f3ec2909444
2015-12-22 22:34:09 +08:00
LOCAL_NOTICE_FILE:=
Rebuild odex files in PDK fusion build. To rebuild odex files of Java libraries and apps, we store the jars/apks without stripping the classes.dex inside the platform.zip. We also save the build variables that may affect how we rebuild an odex in pdk_dexpreopt_config.mk in the platform.zip. We store the files and configuration only for libraries/apps that get installed to the system.img (or vendor.img). In PDK fusion build, we auto-generate prebuilt module definitions for the javalib.jar and package.dex.apk carried in the platform.zip, using configuration stored in pdk_dexpreopt_config.mk. With the prebult modules, we override the implicit rule that directly copies the odex from the platform.zip. To rebuild odex of javalib.jar, we added support for prebuilt shared Java library to prebiult_internal.mk. An installable prebuilt Java library is treated as shared Java library, i.e. with classes.dex in the jar instead of a set of .class files. For apks in the platform.zip, we install the stripped version from platform files inside platform.zip, instead of the package.dex.apk, using a new variable LOCAL_REPLACE_PREBUILT_APK_INSTALLED. We can't strip package.dex.apk because we can't re-sign the stripped apk at this point. We generate prebuilt module only if it's not already defined in the source tree. Bug: 27543283 Change-Id: I9e146f8b713d6f57c397fd28d88c9ab700757ca1 (cherry-pick from commit 3a61eeb6cb588b9a206bd80814183bcc0263cd13)
2016-03-12 02:32:01 +08:00
# Used to replace the installed file of a presigned prebuilt apk in PDK fusion build,
# to avoid installing the presigned apks with classes.dex unstripped.
LOCAL_REPLACE_PREBUILT_APK_INSTALLED:=
Add LOCAL_NDK_VERSION. Used to select between releases of the NDK (r10, r11, etc). Some of the libraries we use in Android come as prebuilts from google3, which are most likely built against an older NDK than what we have in the platform. Since things may not be ABI compatible release to release, we need to keep legacy versions accessible for those to keep building. Change-Id: Ia3df42fa6f3a7bd5108ff6bbb0f2ca06239c3be9
2016-03-31 05:13:50 +08:00
LOCAL_NDK_VERSION:=current
Add LOCAL_COPY_TO_INTERMEDIATE_LIBRARIES. This allows a module to avoid being installed to the common library directory. Test: Prevents copying of NDK libraries with the NDK sysroot patches. Bug: http://b/27533932 Change-Id: I24f11d5a70595bcd524ac5bd85034c226d2de211
2016-07-21 02:02:18 +08:00
LOCAL_COPY_TO_INTERMEDIATE_LIBRARIES:=
Add LOCAL_LOGTAGS_FILES that prebuilts can use Soong modules can define logtags files that need to be combined into /system/etc/event-log-tags, so add a new LOCAL_LOGTAGS_FILES variable that can be used to specify *.logtags file outside of LOCAL_SRC_FILES. Bug: 28989759 Change-Id: I53c5d396dfb7c6006806758f351eb5cdde90fe74
2016-06-02 06:27:11 +08:00
LOCAL_LOGTAGS_FILES:=
Record module type statistics Creates a build_system_stats.txt build artifact that contains statistics on how many BUILD_* modules are defined in a build. Also writes out information about the Soong module types sent from the Soong build. Merged-In: Iaf0c7062f542dc6942b5349854f3d49267cac4a5 Change-Id: Iaf0c7062f542dc6942b5349854f3d49267cac4a5
2016-07-26 07:03:53 +08:00
LOCAL_RECORDED_MODULE_TYPE:=
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
# arch specific variables
LOCAL_SRC_FILES_$(TARGET_ARCH):=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE_$(TARGET_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_CFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_CFLAGS_$(TARGET_ARCH):=
don't use LOCAL_*_arch for host builds The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host modules, only append use them for target modules. Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be consistent. Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
2014-02-13 13:15:12 +08:00
LOCAL_CPPFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_CPPFLAGS_$(TARGET_ARCH):=
Support arch-specific LOCAL_C_INCLUDES. Bug: 11654773 Change-Id: I89c7ce7ff8bea15cb81f9cd9b0188b54beed3422
2014-01-28 02:27:19 +08:00
LOCAL_C_INCLUDES_$(TARGET_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_ASFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_ASFLAGS_$(TARGET_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_LDFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_LDFLAGS_$(TARGET_ARCH):=
add support for more LOCAL_*_arch variables Add support for: LOCAL_SHARED_LIBRARIES_arch LOCAL_STATIC_LIBRARIES_arch LOCAL_WHOLE_STATIC_LIBRARIES_arch LOCAL_GENERATED_SOURCES_arch LOCAL_REQUIRED_MODULES_arch Change-Id: Iad91702e140d8dba7dcaee13f236c77b1e626a34
2014-02-05 06:53:25 +08:00
LOCAL_SHARED_LIBRARIES_$(TARGET_ARCH):=
LOCAL_STATIC_LIBRARIES_$(TARGET_ARCH):=
LOCAL_WHOLE_STATIC_LIBRARIES_$(TARGET_ARCH):=
LOCAL_GENERATED_SOURCES_$(TARGET_ARCH):=
LOCAL_REQUIRED_MODULES_$(TARGET_ARCH):=
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_CLANG_$(TARGET_ARCH):=
Support to add JNI of both archs in multilib build. Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in multilib build. The build system will package jni of both archs to the apk, or install them to the right location on the system image and create symlinks, extract .so files from prebuilt apk, etc if appropriate. Bug: 15849902 Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
2014-06-25 11:01:52 +08:00
LOCAL_PREBUILT_JNI_LIBS_$(TARGET_ARCH):=
Support arch specific variants of LOCAL_STRIP_MODULE/LOCAL_PACK_MODULE_RELOCATIONS So that we can disable only one in multilib modules. Bug: 27442756 Change-Id: I4ca379fac997f9165c47cb93d34bf1f483f5a241 (cherry-pick from commit b6eb8ddbde11de0bc59cfedf7adb91a83c27d279)
2016-03-02 12:14:52 +08:00
LOCAL_STRIP_MODULE_$(TARGET_ARCH):=
LOCAL_PACK_MODULE_RELOCATIONS_$(TARGET_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
ifdef TARGET_2ND_ARCH
LOCAL_SRC_FILES_$(TARGET_2ND_ARCH):=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_CFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_CFLAGS_$(TARGET_2ND_ARCH):=
don't use LOCAL_*_arch for host builds The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host modules, only append use them for target modules. Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be consistent. Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
2014-02-13 13:15:12 +08:00
LOCAL_CPPFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_CPPFLAGS_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_C_INCLUDES. Bug: 11654773 Change-Id: I89c7ce7ff8bea15cb81f9cd9b0188b54beed3422
2014-01-28 02:27:19 +08:00
LOCAL_C_INCLUDES_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_ASFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_ASFLAGS_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
LOCAL_LDFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_LDFLAGS_$(TARGET_2ND_ARCH):=
add support for more LOCAL_*_arch variables Add support for: LOCAL_SHARED_LIBRARIES_arch LOCAL_STATIC_LIBRARIES_arch LOCAL_WHOLE_STATIC_LIBRARIES_arch LOCAL_GENERATED_SOURCES_arch LOCAL_REQUIRED_MODULES_arch Change-Id: Iad91702e140d8dba7dcaee13f236c77b1e626a34
2014-02-05 06:53:25 +08:00
LOCAL_SHARED_LIBRARIES_$(TARGET_2ND_ARCH):=
LOCAL_STATIC_LIBRARIES_$(TARGET_2ND_ARCH):=
LOCAL_WHOLE_STATIC_LIBRARIES_$(TARGET_2ND_ARCH):=
LOCAL_GENERATED_SOURCES_$(TARGET_2ND_ARCH):=
LOCAL_REQUIRED_MODULES_$(TARGET_2ND_ARCH):=
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_CLANG_$(TARGET_2ND_ARCH):=
Support to add JNI of both archs in multilib build. Use "LOCAL_MULTILIB := both" to install jni libraries of both archs in multilib build. The build system will package jni of both archs to the apk, or install them to the right location on the system image and create symlinks, extract .so files from prebuilt apk, etc if appropriate. Bug: 15849902 Change-Id: I7e147b5a47db476584c38250de7b36c75ea40d81
2014-06-25 11:01:52 +08:00
LOCAL_PREBUILT_JNI_LIBS_$(TARGET_2ND_ARCH):=
Support arch specific variants of LOCAL_STRIP_MODULE/LOCAL_PACK_MODULE_RELOCATIONS So that we can disable only one in multilib modules. Bug: 27442756 Change-Id: I4ca379fac997f9165c47cb93d34bf1f483f5a241 (cherry-pick from commit b6eb8ddbde11de0bc59cfedf7adb91a83c27d279)
2016-03-02 12:14:52 +08:00
LOCAL_STRIP_MODULE_$(TARGET_2ND_ARCH):=
LOCAL_PACK_MODULE_RELOCATIONS_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
endif
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_SRC_FILES_$(HOST_ARCH):=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_CFLAGS_$(HOST_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_CFLAGS_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_CPPFLAGS_$(HOST_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_CPPFLAGS_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_C_INCLUDES_$(HOST_ARCH):=
LOCAL_ASFLAGS_$(HOST_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_ASFLAGS_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_LDFLAGS_$(HOST_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_LDFLAGS_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_SHARED_LIBRARIES_$(HOST_ARCH):=
LOCAL_STATIC_LIBRARIES_$(HOST_ARCH):=
LOCAL_WHOLE_STATIC_LIBRARIES_$(HOST_ARCH):=
LOCAL_GENERATED_SOURCES_$(HOST_ARCH):=
LOCAL_REQUIRED_MODULES_$(HOST_ARCH):=
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_CLANG_$(HOST_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
ifdef HOST_2ND_ARCH
LOCAL_SRC_FILES_$(HOST_2ND_ARCH):=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_CFLAGS_$(HOST_2ND_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_CFLAGS_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_CPPFLAGS_$(HOST_2ND_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_CPPFLAGS_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_C_INCLUDES_$(HOST_2ND_ARCH):=
LOCAL_ASFLAGS_$(HOST_2ND_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_ASFLAGS_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_LDFLAGS_$(HOST_2ND_ARCH):=
Clear all LOCAL_CLANG_*FLAGS*. Although only some of these flags will be used for some targets or hosts, they must all be cleared to avoid carrying over from one project to another. BUG: 17677366 Change-Id: I6d26fa7e5bf2ff11758728810d4874f3759aebe7
2014-10-01 05:23:14 +08:00
LOCAL_CLANG_LDFLAGS_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
LOCAL_SHARED_LIBRARIES_$(HOST_2ND_ARCH):=
LOCAL_STATIC_LIBRARIES_$(HOST_2ND_ARCH):=
LOCAL_WHOLE_STATIC_LIBRARIES_$(HOST_2ND_ARCH):=
LOCAL_GENERATED_SOURCES_$(HOST_2ND_ARCH):=
LOCAL_REQUIRED_MODULES_$(HOST_2ND_ARCH):=
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_CLANG_$(HOST_2ND_ARCH):=
Support host multilib build This change basically ported our target multilib to the host side. It supports 2 host build modes: x86 and x86_64 multilib build. For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64 multilib build. Later we'll default to x86_64 build and have a flag to force 32-bit only build, which may be needed by SDK build. In host module definition, like in target ones, you can use the following LOCAL variables to set up multilib configuration: LOCAL_MULTILIB: can be "both", "first", "32" or "64". It also supports the same set of arch or 32-vs-64 specific LOCAL variables. By default, it builds only for the first arch. To keep path compatibility, in x86_64 build files are still output to out/host/linux-x86; Both 32-bit and 64-bit executables are in out/host/linux-86/bin; In x86_64 build 32-bit shared libraries are installed to out/host/linux-x86/lib32 and 64-bit shared libraries are installed to out/host/linux-x86/lib; 32-bit object files are output to out/host/linux-x86/obj32 and 64-bit object files are output to out/host/linux-x86/obj. Bug: 13751317 Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
2014-04-18 01:03:35 +08:00
endif
Support arch-specific LOCAL_ variables With those variables, you can set up different values for TARGET_ARCH and TARGET_2ND_ARCH. Also fixed a couple of variables. Bug: 11654773 Change-Id: I4c7684a562cd5877d18f67d4f848b8df07d0103b
2014-01-24 07:09:04 +08:00
Add _(darwin|linux|windows) So that we can support building both linux and windows binaries at the same time on a linux host. This replaces the ifeq($(HOST_OS),...) checks in Android.mk files. Bug: 23566667 Change-Id: I693e11984e36d55bb6f09fa0d49bc485463e16fb
2015-08-14 08:51:40 +08:00
LOCAL_SRC_FILES_$(HOST_OS):=
LOCAL_STATIC_LIBRARIES_$(HOST_OS):=
LOCAL_SHARED_LIBRARIES_$(HOST_OS):=
LOCAL_CFLAGS_$(HOST_OS):=
LOCAL_CPPFLAGS_$(HOST_OS):=
LOCAL_LDFLAGS_$(HOST_OS):=
LOCAL_LDLIBS_$(HOST_OS):=
LOCAL_ASFLAGS_$(HOST_OS):=
LOCAL_C_INCLUDES_$(HOST_OS):=
LOCAL_GENERATED_SOURCES_$(HOST_OS):=
LOCAL_REQUIRED_MODULES_$(HOST_OS):=
Add HOST_CROSS_OS Instead of using recursive make to change the HOST_OS when building the windows SDK under linux, add the concept of cross-building to another host os. Bug: 23566667 Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
2015-08-15 03:59:50 +08:00
ifdef HOST_CROSS_OS
LOCAL_SRC_FILES_$(HOST_CROSS_OS):=
LOCAL_STATIC_LIBRARIES_$(HOST_CROSS_OS):=
LOCAL_SHARED_LIBRARIES_$(HOST_CROSS_OS):=
LOCAL_CFLAGS_$(HOST_CROSS_OS):=
LOCAL_CPPFLAGS_$(HOST_CROSS_OS):=
LOCAL_LDFLAGS_$(HOST_CROSS_OS):=
LOCAL_LDLIBS_$(HOST_CROSS_OS):=
LOCAL_ASFLAGS_$(HOST_CROSS_OS):=
LOCAL_C_INCLUDES_$(HOST_CROSS_OS):=
LOCAL_GENERATED_SOURCES_$(HOST_CROSS_OS):=
LOCAL_REQUIRED_MODULES_$(HOST_CROSS_OS):=
endif
Add support for LOCAL_SRC_FILES_(host)_(arch) For boringssl, which has architecture specific host assembly files Bug: 23566667 Change-Id: Ia4602d28e93a1b3d1400cf95417b5e446c5fb84b
2015-08-19 08:47:06 +08:00
LOCAL_SRC_FILES_$(HOST_OS)_$(HOST_ARCH):=
ifdef HOST_2ND_ARCH
LOCAL_SRC_FILES_$(HOST_OS)_$(HOST_2ND_ARCH):=
endif
Add HOST_CROSS_OS Instead of using recursive make to change the HOST_OS when building the windows SDK under linux, add the concept of cross-building to another host os. Bug: 23566667 Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
2015-08-15 03:59:50 +08:00
ifdef HOST_CROSS_OS
LOCAL_SRC_FILES_$(HOST_CROSS_OS)_$(HOST_CROSS_ARCH):=
Add 64-bit windows cross-compiles This is mostly the same as the existing 2ND_HOST / HOST_CROSS support. The interesting thing I did here was make x86 the 'first' architecture, and x86_64 the second. This way LOCAL_MULTILIB := first defaults to 32-bit windows modules. windows-x86/bin <- defaults to 32-bit executables windows-x86/lib <- 32-bit libraries, like before windows-x86/lib64 <- 64-bit libraries windows-x86/obj <- 32-bit intermediates windows-x86/obj64 <- 64-bit intermediates Then modules are registered with the names: host_cross_liblog <- 32-bit, like before host_cross_liblog_64 <- 64-bit Bug: 26957718 Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
2016-02-06 08:20:19 +08:00
ifdef HOST_CROSS_2ND_ARCH
LOCAL_SRC_FILES_$(HOST_CROSS_OS)_$(HOST_CROSS_2ND_ARCH):=
endif
Add HOST_CROSS_OS Instead of using recursive make to change the HOST_OS when building the windows SDK under linux, add the concept of cross-building to another host os. Bug: 23566667 Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
2015-08-15 03:59:50 +08:00
endif
Add support for LOCAL_SRC_FILES_(host)_(arch) For boringssl, which has architecture specific host assembly files Bug: 23566667 Change-Id: Ia4602d28e93a1b3d1400cf95417b5e446c5fb84b
2015-08-19 08:47:06 +08:00
don't use LOCAL_*_arch for host builds The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host modules, only append use them for target modules. Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be consistent. Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
2014-02-13 13:15:12 +08:00
LOCAL_SRC_FILES_32:=
LOCAL_SRC_FILES_64:=
Add support for LOCAL_SRC_FILES_EXCLUDE LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of LOCAL_SRC_FILES. A common usage will be to use LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be replaced with an arch-optimized version. Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
2015-07-01 03:21:59 +08:00
LOCAL_SRC_FILES_EXCLUDE_32:=
LOCAL_SRC_FILES_EXCLUDE_64:=
don't use LOCAL_*_arch for host builds The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host modules, only append use them for target modules. Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be consistent. Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
2014-02-13 13:15:12 +08:00
LOCAL_SHARED_LIBRARIES_32:=
LOCAL_SHARED_LIBRARIES_64:=
LOCAL_STATIC_LIBRARIES_32:=
LOCAL_STATIC_LIBRARIES_64:=
LOCAL_WHOLE_STATIC_LIBRARIES_32:=
LOCAL_WHOLE_STATIC_LIBRARIES_64:=
LOCAL_GENERATED_SOURCES_32:=
LOCAL_GENERATED_SOURCES_64:=
build: support LOCAL_*_32 and LOCAL_*_64 Support the following new variables based on whether the current multilib target is 32 bit or 64 bit: LOCAL_CFLAGS_32 LOCAL_CFLAGS_64 LOCAL_LDFLAGS_32 LOCAL_LDFLAGS_64 LOCAL_ASFLAGS_32 LOCAL_ASFLAGS_64 LOCAL_C_INCLUDES_32 LOCAL_C_INCLUDES_64 Change-Id: Ia868d56dff114be301bf8297eec768675f186927
2014-01-30 09:46:37 +08:00
LOCAL_CFLAGS_32:=
LOCAL_CFLAGS_64:=
don't use LOCAL_*_arch for host builds The LOCAL_*_$(TARGET_ARCH) variables don't make sense for host modules, only append use them for target modules. Also complete the list of LOCAL_*_arch and LOCAL_*_32/64 to be consistent. Change-Id: I00c83e5c4e08ed9a844f9f99a79ce4bcc3f0bf11
2014-02-13 13:15:12 +08:00
LOCAL_CPPFLAGS_32:=
LOCAL_CPPFLAGS_64:=
build: support LOCAL_*_32 and LOCAL_*_64 Support the following new variables based on whether the current multilib target is 32 bit or 64 bit: LOCAL_CFLAGS_32 LOCAL_CFLAGS_64 LOCAL_LDFLAGS_32 LOCAL_LDFLAGS_64 LOCAL_ASFLAGS_32 LOCAL_ASFLAGS_64 LOCAL_C_INCLUDES_32 LOCAL_C_INCLUDES_64 Change-Id: Ia868d56dff114be301bf8297eec768675f186927
2014-01-30 09:46:37 +08:00
LOCAL_LDFLAGS_32:=
LOCAL_LDFLAGS_64:=
LOCAL_ASFLAGS_32:=
LOCAL_ASFLAGS_64:=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 08:13:48 +08:00
LOCAL_CLANG_CFLAGS_32:=
LOCAL_CLANG_CFLAGS_64:=
LOCAL_CLANG_CPPFLAGS_32:=
LOCAL_CLANG_CPPFLAGS_64:=
LOCAL_CLANG_LDFLAGS_32:=
LOCAL_CLANG_LDFLAGS_64:=
LOCAL_CLANG_ASFLAGS_32:=
LOCAL_CLANG_ASFLAGS_64:=
build: support LOCAL_*_32 and LOCAL_*_64 Support the following new variables based on whether the current multilib target is 32 bit or 64 bit: LOCAL_CFLAGS_32 LOCAL_CFLAGS_64 LOCAL_LDFLAGS_32 LOCAL_LDFLAGS_64 LOCAL_ASFLAGS_32 LOCAL_ASFLAGS_64 LOCAL_C_INCLUDES_32 LOCAL_C_INCLUDES_64 Change-Id: Ia868d56dff114be301bf8297eec768675f186927
2014-01-30 09:46:37 +08:00
LOCAL_C_INCLUDES_32:=
LOCAL_C_INCLUDES_64:=
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 Some executables will need to be built for both 32-bit and 64-bit. For tests, it will be convienient to keep the name of the executable the same, but install them in a different location. Add LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module to specify different paths for 32-bit and 64-bit executables. Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
2014-03-22 03:25:44 +08:00
LOCAL_MODULE_PATH_32:=
LOCAL_MODULE_PATH_64:=
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 Some executables will need to be built for both 32-bit and 64-bit. For linker/linker64, debuggerd/debuggerd64, and a few more, they will be installed in the same path (/system/bin), but with different filenames. Allow the module to specify LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 to name the two versions. Change-Id: I573e8678c7332245a064f31246be0a05f0a9e25f
2014-03-22 03:27:37 +08:00
LOCAL_MODULE_STEM_32:=
LOCAL_MODULE_STEM_64:=
Support LOCAL_CLANG with arch/bit suffix. Precedence: LOCAL_CLANG_<arch> > LOCAL_CLANG_<32|64> > LOCAL_CLANG. Bug: 15257067 Change-Id: I86b72f3bec162834591287d3b5231b5f40f9a431
2014-05-28 04:03:36 +08:00
LOCAL_CLANG_32:=
LOCAL_CLANG_64:=
Support LOCAL_INIT_RC. A module can install a companion init.rc file, by specifying: LOCAL_INIT_RC := <init.rc-file-path-replative-to-LOCAL_PATH> You can also use the variant with _32 or _64 suffix. Bug: 23186545 Change-Id: I00a96509f5707ae39361a0c5555fa59d46c90322
2015-08-21 03:02:10 +08:00
LOCAL_INIT_RC_32:=
LOCAL_INIT_RC_64:=
Add support for LOCAL_MODULE_SYMLINKS Specifying LOCAL_MODULE_SYMLINKS will create symlinks to the installed module in the same directory. Change-Id: Idecb2b75f0c9999eb000eed9a79a989244ccf6c2
2016-07-15 07:02:57 +08:00
LOCAL_MODULE_SYMLINKS_32:=
LOCAL_MODULE_SYMLINKS_64:=
Allow java targets to support 1.8 source / target This change enables build rules to specify: LOCAL_JAVA_LANGUAGE_VERSION := 1.8 to enable -source 1.8 -target 1.8 for javac and equivalent flags for Jack. Bug: 26753820 (cherry-picked from commit cdfbe4a8522b9a13ffe6ac1f826a1d6760f87d60) Change-Id: I361c99dd599e7b4a041f02c9562e461da2b0502e
2016-01-16 11:41:26 +08:00
LOCAL_JAVA_LANGUAGE_VERSION:=
Add LOCAL_CTS_GTEST_LIST_EXECUTABLE Change-Id: I9bca66d0e0ef25264b6576d907fa57997e62e8c1
2016-03-03 12:36:57 +08:00
LOCAL_CTS_GTEST_LIST_EXECUTABLE:=
build: support LOCAL_*_32 and LOCAL_*_64 Support the following new variables based on whether the current multilib target is 32 bit or 64 bit: LOCAL_CFLAGS_32 LOCAL_CFLAGS_64 LOCAL_LDFLAGS_32 LOCAL_LDFLAGS_64 LOCAL_ASFLAGS_32 LOCAL_ASFLAGS_64 LOCAL_C_INCLUDES_32 LOCAL_C_INCLUDES_64 Change-Id: Ia868d56dff114be301bf8297eec768675f186927
2014-01-30 09:46:37 +08:00
auto import from //depot/cupcake/@135843
2009-03-04 11:28:42 +08:00
# Trim MAKEFILE_LIST so that $(call my-dir) doesn't need to
# iterate over thousands of entries every time.
# Leave the current makefile to make sure we don't break anything
# that expects to be able to find the name of the current makefile.
MAKEFILE_LIST := $(lastword $(MAKEFILE_LIST))