tequilaOS/platform_build
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_build/core/clear_vars.mk

289 lines
8.2 KiB
Makefile
Raw Normal View History

auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 04:23:40 +01:00
LOCAL_MODULE_RELATIVE_PATH :=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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-17 21:33:40 +02:00
LOCAL_DONT_CHECK_MODULE:=
LOCAL_CHECKED_MODULE:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 00:56:11 +02: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 01:46:52 +02:00
LOCAL_PICKUP_FILES:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 05:36:42 +01: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 00:42:11 +02:00
LOCAL_PACKAGE_SPLITS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01:00
LOCAL_REQUIRED_MODULES:=
LOCAL_ACP_UNAVAILABLE:=
LOCAL_MODULE_TAGS:=
LOCAL_SRC_FILES:=
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-29 23:48:32 +01:00
LOCAL_STATIC_JAVA_AAR_LIBRARIES:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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-25 23:22:41 +02: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 04:28:42 +01:00
LOCAL_WHOLE_STATIC_LIBRARIES:=
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 02:41:52 +02:00
LOCAL_FDO_SUPPORT:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 02:15:47 +02:00
LOCAL_CLANG_ASFLAGS:=
LOCAL_CLANG_CFLAGS:=
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-15 19:59:10 +02:00
LOCAL_CONLYFLAGS:=
Allow per module RTTI setting. This fixes a bug in previous check-ins. Change-Id: I5fcac192a7945720fd7667f7497078d310370bc5
2011-06-07 19:55:48 +02:00
LOCAL_RTTI_FLAG:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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-08 18:31:21 +01:00
LOCAL_EXPORT_C_INCLUDE_DIRS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01:00
LOCAL_LDFLAGS:=
Add LOCAL_CLANG_*FLAGS for clang only flags. To be used only for some modules. Change-Id: I107ec37f11f738f860598f0c86c4ad7ec20c9011
2014-09-05 02:15:47 +02:00
LOCAL_CLANG_LDFLAGS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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-28 22:14:29 +01:00
LOCAL_AAPT_INCLUDE_ALL_RESOURCES:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 06:50:51 +02:00
LOCAL_PREBUILT_STRIP_COMMENTS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01:00
LOCAL_INTERMEDIATE_SOURCES:=
fix typo Change-Id: Ic00f82ea7bbe570ef30f52b353ba147664d755d7
2010-05-18 03:40:39 +02: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-01 20:13:32 +01:00
LOCAL_JAVACFLAGS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 05:37:35 +01:00
LOCAL_JAVA_LAYERS_FILE:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01:00
LOCAL_NO_STANDARD_LIBRARIES:=
LOCAL_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 04:31:12 +02:00
LOCAL_DROIDDOC_USE_STANDARD_DOCLET:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 00:45:45 +01:00
LOCAL_ADDITIONAL_HTML_DIR:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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_COMPRESS_MODULE_SYMBOLS:=
LOCAL_STRIP_MODULE:=
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 09:38:07 +02: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 05:13:41 +02:00
LOCAL_PREBUILT_JNI_LIBS:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 02:04:55 +01:00
LOCAL_APK_LIBRARIES:=
Temporarily use a separate var for including shared resources Change-Id: I56636a1d7dfdaa070706f1991f80e03fe2f71069
2014-03-25 23:45:34 +01: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 00:41:01 +02:00
LOCAL_MANIFEST_INSTRUMENTATION_FOR:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01:00
LOCAL_AIDL_INCLUDES:=
LOCAL_JARJAR_RULES:=
LOCAL_ADDITIONAL_JAVA_DIR:=
LOCAL_ALLOW_UNDEFINED_SYMBOLS:=
LOCAL_DX_FLAGS:=
LOCAL_CERTIFICATE:=
LOCAL_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 02:34:29 +02: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 03:53:53 +01: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 01:59:01 +02: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 03:32:49 +02: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-30 22:39:24 +02:00
LOCAL_PROGUARD_FLAGS:=
Separate out Proguard flag files to fix dependency. Bug: 3048005 Change-Id: I3e77ca1082cf7c92a43b249e5c887e3fbdf4ba11
2010-09-29 23:50:41 +02:00
LOCAL_PROGUARD_FLAG_FILES:=
resolved conflicts for merge of 4df82b3e to klp-dev-plus-aosp Change-Id: I7a1d9e1954ede06a818814bd05a77c69f1ed3bc6
2014-02-08 19:31:36 +01: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 00:48:03 +01: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-07 20:42:19 +02: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-12 19:20:53 +02: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-23 20:03:29 +02: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 03:24:45 +01:00
LOCAL_FULL_LIBS_MANIFEST_FILES:=
Now slang supports "-I" options. Change-Id: I32aef6c913d9d30f9982a593397145f1562aecf9
2010-09-01 22:28:52 +02:00
LOCAL_RENDERSCRIPT_INCLUDES:=
Provide mechanism to override llvm-rs-cc headers. Change-Id: I87fd496069a9dfde633e2d232e436fa5d7315cc0
2011-08-24 07:01:49 +02:00
LOCAL_RENDERSCRIPT_INCLUDES_OVERRIDE:=
Support custom RenderScript compiler Change-Id: I85e38e84565e04f99dd26217f280274883dc322d
2011-05-26 02:16:22 +02:00
LOCAL_RENDERSCRIPT_CC:=
Build rules for Renderscript compatibility library. Bug: 7419958 Change-Id: I2e0f0bb632e6ff22b2cf1a1b96b28364637995cc
2012-11-29 01:52:41 +01:00
LOCAL_RENDERSCRIPT_COMPATIBILITY:=
Enable -Wall/-Werror with LOCAL_RENDERSCRIPT_FLAGS. Change-Id: Ia2a058e6711839d89072c2e96f0c60aa4cedda6b
2011-12-07 03:43:24 +01:00
LOCAL_RENDERSCRIPT_FLAGS:=
Copy RS compatibility libraries to /system/lib/ for bundled builds. Bug: 8138884 Change-Id: I74fb0c5835974af3c6e34fcd2d9ebfc2e7b08b4d
2013-02-07 01:19:30 +01:00
LOCAL_RENDERSCRIPT_SKIP_INSTALL:=
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 03:53:53 +02: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-24 21:17:03 +02: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-13 22:57:28 +02: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 03:07:23 +02:00
LOCAL_DEX_PREOPT_FLAGS:=
Add a "nano" option to LOCAL_PROTOC_OPTIMIZE_TYPE. Change-Id: I7429015b3c5f7f38b7be01eb2d4927f7a9999c80
2013-03-28 22:02:14 +01:00
LOCAL_PROTOC_OPTIMIZE_TYPE:= # lite(default),micro,nano,full
Allow module-specific protoc flags. You can add local protoc flags via LOCAL_PROTOC_FLAGS. Change-Id: If246a4edafe1edcec6a7f193bde8ce3c83de745b
2010-11-05 19:30:58 +01:00
LOCAL_PROTOC_FLAGS:=
Allow proto builds to pass in java proto params. Change-Id: I65fe0cd96f818f59267da6159e6bd2ad28f07a11
2013-07-25 21:28:19 +02: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 05:15:00 +01:00
LOCAL_NO_CRT:=
Install path support for vendor modules. Bug: 5284764 Set "LOCAL_PROPRIETARY_MODULE := true" to install module to vendor partition. Change-Id: I1301acc10664a12e313f3b868d9fd6400ac8b133
2011-09-13 22:57:26 +02: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 01:13:27 +01:00
LOCAL_OEM_MODULE:=
Install to TARGET_OUT_APPS_PRIVILEGED if LOCAL_PRIVILEGED_MODULE is true Change-Id: I268b8652f18034aa3fdd3126ebf6196f78c4bbb2
2013-05-09 00:49:08 +02: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 00:11:57 +01: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 08:54:49 +01: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 00:49:58 +01: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 15:00:16 +01:00
LOCAL_CLANG:=
Add support for building with AddressSanitizer. Change-Id: I559d21bbeb9f869f51e48ce18247ceaf766768b4
2012-03-30 10:15:12 +02:00
LOCAL_ADDRESS_SANITIZER:=
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-19 19:40:37 +02:00
LOCAL_JAR_EXCLUDE_FILES:=
Split framework jar. Change-Id: I38c68ac169a4ea10e4640b5d8e24298a6caaf441
2013-07-18 05:29:51 +02: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 03:41:19 +02:00
LOCAL_JAR_EXCLUDE_PACKAGES:=
lint support. Bug: 6167394 $make lint-<app-name> # to lint on a single module $make lintall # to lint on all packages in the source tree. Change-Id: I4decc76fb75793ce44809232b0ec72b766fbb434
2012-06-19 03:45:40 +02:00
LOCAL_LINT_FLAGS:=
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-19 23:38:43 +02: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-30 21:59:42 +02: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-13 19:55:28 +01: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 03:23:01 +01: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 00:46:43 +02: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-06 20:44:41 +01:00
LOCAL_POST_INSTALL_CMD:=
Support to dist unbundled files for bundled build Usage: LOCAL_DIST_BUNDLED_BINARIES := true The dist files will include the jni shared libraries and the apk with jni libraries stripped. Bug: 8181626 Change-Id: I4a047d786ad35b948b4ad7a51adf37321dbe395c
2013-04-11 04:17:41 +02:00
LOCAL_DIST_BUNDLED_BINARIES:=
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-13 21:35:10 +02:00
LOCAL_HAL_STATIC_LIBRARIES:=
Support to optionally run rmtypedefs. Bug: 10330586 Change-Id: I6ddfca2ec986cf2c82b0942b7a5360508f095e9a
2013-08-15 01:59:00 +02: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 11:55:46 +02: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 11:37:14 +02:00
LOCAL_NO_STATIC_ANALYZER:=
build: rename LOCAL_32BIT_ONLY to LOCAL_32_BIT_ONLY Rename for consistency with TARGET_IS_64_BIT. Change-Id: I824dcaed0c1e88b8246bcffb21ab3f1772175926
2014-01-30 03:20:01 +01: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-27 22:03:36 +02: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-06 23:45:37 +01: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-17 19:03:35 +02:00
LOCAL_MODULE_HOST_ARCH:=
Add LOCAL_NO_FPIE. Not all executables should be built with -pie. bug 15814177 Change-Id: I402e8a531866b507ee80a0bf677f9f3551ca7693
2014-09-04 00:01:46 +02: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-12 23:46:57 +02: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-19 23:25:57 +02: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 01:56:04 +01:00
LOCAL_DPI_VARIANTS:=
LOCAL_DPI_FILE_STEM:=
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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 00:09:04 +01:00
# arch specific variables
LOCAL_SRC_FILES_$(TARGET_ARCH):=
LOCAL_CFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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 06:15:12 +01:00
LOCAL_CPPFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02:00
LOCAL_CLANG_CPPFLAGS_$(TARGET_ARCH):=
Support arch-specific LOCAL_C_INCLUDES. Bug: 11654773 Change-Id: I89c7ce7ff8bea15cb81f9cd9b0188b54beed3422
2014-01-27 19:27:19 +01: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 00:09:04 +01:00
LOCAL_ASFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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 00:09:04 +01:00
LOCAL_NO_CRT_$(TARGET_ARCH):=
LOCAL_LDFLAGS_$(TARGET_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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-04 23:53:25 +01: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-27 22:03:36 +02: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 05:01:52 +02:00
LOCAL_PREBUILT_JNI_LIBS_$(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 00:09:04 +01:00
ifdef TARGET_2ND_ARCH
LOCAL_SRC_FILES_$(TARGET_2ND_ARCH):=
LOCAL_CFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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 06:15:12 +01:00
LOCAL_CPPFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02:00
LOCAL_CLANG_CPPFLAGS_$(TARGET_2ND_ARCH):=
Support arch-specific LOCAL_C_INCLUDES. Bug: 11654773 Change-Id: I89c7ce7ff8bea15cb81f9cd9b0188b54beed3422
2014-01-27 19:27:19 +01: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 00:09:04 +01:00
LOCAL_ASFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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 00:09:04 +01:00
LOCAL_NO_CRT_$(TARGET_2ND_ARCH):=
LOCAL_LDFLAGS_$(TARGET_2ND_ARCH):=
Add local Clang+target specific flags. BUG: 17677366 Change-Id: I75522fb56fdf4d27ea1f5f0ae15866b13ae6e206
2014-09-27 02:13:48 +02: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-04 23:53:25 +01: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-27 22:03:36 +02: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 05:01:52 +02:00
LOCAL_PREBUILT_JNI_LIBS_$(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 00:09:04 +01: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-17 19:03:35 +02:00
LOCAL_SRC_FILES_$(HOST_ARCH):=
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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-09-30 23:23:14 +02: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-17 19:03:35 +02:00
LOCAL_NO_CRT_$(HOST_ARCH):=
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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-27 22:03:36 +02: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-17 19:03:35 +02:00
ifdef HOST_2ND_ARCH
LOCAL_SRC_FILES_$(HOST_2ND_ARCH):=
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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-09-30 23:23:14 +02: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-17 19:03:35 +02:00
LOCAL_NO_CRT_$(HOST_2ND_ARCH):=
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-09-30 23:23:14 +02: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-17 19:03:35 +02: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-27 22:03:36 +02: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-17 19:03:35 +02: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 00:09:04 +01: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 06:15:12 +01:00
LOCAL_SRC_FILES_32:=
LOCAL_SRC_FILES_64:=
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 02:46:37 +01: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 06:15:12 +01: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 02:46:37 +01: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 02:13:48 +02: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 02:46:37 +01: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-21 20:25:44 +01: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-21 20:27:37 +01: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-27 22:03:36 +02:00
LOCAL_CLANG_32:=
LOCAL_CLANG_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 02:46:37 +01:00
auto import from //depot/cupcake/@135843
2009-03-04 04:28:42 +01: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))
Reference in a new issue Copy permalink