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
* commit '054b0274fc27babb42a60002ad25c9e608eac257':
add support for more LOCAL_*_arch variables
don't rename 32-bit executables to *_32
remove 2nd arch from ARCH_ARM_* defines
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
