Delete LOCAL_NO_2ND_ARCH, it is no longer used. Equivalent
functionality is available with LOCAL_MULTILIB := first.
Change-Id: I36838a8a7e10b0a59ca0022c4c8a3a190e782c71
LOCAL_MULTILIB replaces LOCAL_32_BIT_ONLY and
LOCAL_NO_2ND_ARCH, although both are still supported.
Set LOCAL_MULTILIB := 32 to always build a module 32-bit.
This is the same as specifying LOCAL_32_BIT_ONLY.
Set LOCAL_MULTILIB := first to always build a module for
the first architecture (64-bit on a 64-bit target, 32-bit on a
32-bit target). This is the same as specifying LOCAL_NO_2ND_ARCH.
Set LOCAL_MULTILIB := both to build for both architectures
on a mulitlib (64-bit) target.
If LOCAL_MULTILIB is not set libraries will default to "both",
and executables, packages, and prebuilts will default to building
for the first architecture if supported by the module, otherwise
the second.
Executables that set LOCAL_MULTILIB := both must set either
LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64 or
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to specify how to
differentiate the install locations of the two versions.
Change-Id: I22ab6aa342b231c307b1d8a86cea4fd91eea39f5
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
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
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
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
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
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
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
Conflicts:
core/base_rules.mk
By default, an executable is built for TARGET_ARCH.
To build it for TARGET_2ND_ARCH in a 64bit product, use:
LOCAL_32BIT_ONLY := true
To skip a module for TARGET_2ND_ARCH, use:
LOCAL_NO_2ND_ARCH := true
Bug: 11654773
Change-Id: Ieb293d25b21024bfe1b554044df338e064ac7b46
The rules for the 2nd arch are set up in the second inclusion
of static_library_internal.mk.
libfoo of the 2nd arch will be built into
$(PRODUCT_OUT)/obj_$(TARGET_2ND_ARCH)/libfoo_intermediates/libfoo.a.
Bug: 11654773
Change-Id: I1d92733968fc442e9225b4df5bd1b551a81d89f7
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
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
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: I5689586788ef049bd967364f71f31f1e359bd121
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
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
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
This reverts commit 28b46fc16c.
Speculative fix for master builds. I cannot repro the break the bots
are seeing locally, but it seems related to building protobufs and this
CL was in the first broken build.
Also source files which have dependencies need to be bundled together
(at least the way the build system is set up now). Move
--proto_path=$(TOP) to the end so that it does not take precedence
over user-supplied --proto_path flags.
Change-Id: Ia532647fe8811d39230a23ba3671685b0388cbe0
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
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
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
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
Colin Cross