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
But only for static and shared libraries -- we disable building other
types of modules for arm, so don't support the prebuilts for them
either.
This is needed so that we can build these libraries under Soong, and
expose them to Make using BUILD_PREBUILT.
Bug: 27526885
Change-Id: I4f6ec922aed37591b6257b7022b81fb65d05b0fe
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
By resetting we lose LOCAL_*MODULE_STEM values for the second include
of the *_internal.mk.
We don't need to reset because we now store the default value to a
temporary variable my_*module_stem in configure_module_stem.mk.
Bug: 27775991
Change-Id: I36d1ff3d177818677fb38bdb3d340dd2ff34c404
Support TARGET_2ND_ARCH as the binary translation arch.
See target/board/generic_x86_arm/BoardConfig.mk and
target/product/aosp_x86_arm.mk as example for the setup.
In BoardConfig, use the TARGET_2ND_ARCH/etc. variables to set up the
binary translation arch;
Set "TARGET_TRANSLATE_2ND_ARCH := true" to tell the build system it's
not a typical 64-bit multilib configuration.
In product makefile, use "PRODUCT_PACKAGES += libfoo_<2nd_arch>" to
install the TARGET_2ND_ARCH libraries. This also pulls in any dependency
libraries.
By default we don't install any TARGET_2ND_ARCH modules, unless it's
pulled in by PRODUCT_PACKAGES.
Bug: 27526885
Change-Id: I0578e9c80da0532d2fa886a8fcdb140bbc703009
(cherry-pick from commit 277e75a488)
This configures Soong to build windows binaries, which requires support
for 64-bit windows binaries in BUILD_PREBUILT for USE_SOONG=true.
module_arch_supported.mk did not support 64-bit being the secondary
architecture when evaluating multilib conditionals. All other uses of
HOST_*_IS_64_BIT already check the proper version.
Change-Id: Iff664733e6991f4adbe8ddd620b091bbb55d1d86
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
For apps, we don't want to set up the prebuilt apk rule twice even if
"LOCAL_MULTILIB := both", which for apps really means to set up only the
jni library rules twice. See also build/core/install_jni_libs.mk.
Change-Id: Id0406c3c605c6ede613dba06178a1710590c09b3
This uses the fact that unsetting LOCAL_MULTILIB equals "either".
It's useful to build for both 32-bit and 64-bit in the same prebuilt
module definition.
Bug: 13751317
Change-Id: I4f1625a83e13f22f807039afebae73f69ed35918
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
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
Prebuilts often support only a single architecture, allow them to
use LOCAL_MODULE_TARGET_ARCH to specify it.
Change-Id: I2514f66f682ef267bbf1a1ab78510faff0a18b64
This is needed because the linker command line uses -rpath-link with
built module path ($(*_OUT_INTERMEDIATE_LIBRARIES)) to search for indirect
dependency libraries.
Change-Id: I21d537c7c697dfb18df25d3d2bb7bffe2f9d370f
(cherry picked from commit ada8f29657)
This is needed because the linker command line uses -rpath-link with
built module path ($(*_OUT_INTERMEDIATE_LIBRARIES)) to search for indirect
dependency libraries.
Change-Id: I21d537c7c697dfb18df25d3d2bb7bffe2f9d370f
Since commit 6c86a1 we have split LOCAL_SHARED_LIBRARIES out of
LOCAL_REQUIRED_MODULES and the vendor check does no longer cover the
installed modules introduced by LOCAL_SHARED_LIBRARIES.
This change brings back the coverage.
Change-Id: Ie78692e48f173a3350792eb2fee8127ff9433caa
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
To pick up a NOTICE file in LOCAL_PATH and attach it to
/system/lib/libfoo.so, use the following syntax:
include $(CLEAR_VARS)
LOCAL_MODULE_CLASS := NOTICE_FILES
LOCAL_INSTALLED_MODULE := $(PRODUCT_OUT)/system/lib/libfoo.so
include $(BUILD_NOTICE_FILE)
Bug: 7460213
Change-Id: Ie692be72deab37be04d1b578578c131a0885a090
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
Since dev keys can now vary per device, we can't assume they are
checked in with the correct signature.
Change-Id: I7577a3a6bd98d005c15936c99b2944acc4412798
So that prebuilt shared libraries can be referenced with the module name
in other module's Android.mk.
Change-Id: I4c4b471696642694b805b71dd7605b91724ad924
Currently, prebuilt binaries with debug symbols are installed unstripped.
There are only a few of prebuilt shared library (that I'm trying to fix),
so I can do this manually by making intermediate target and applying
TARGET_STRIP, each of them, one by one.
But dynamic_binary.mk has more features than stripping binaries
(like copying unstripped binaries to symbols directory)
and if I do it manually, they will lose all the benefits.
Note that this doesn't change anything when LOCAL_STRIP_MODULE is not set.
I actually tried to force strip every BUILD_PREBUILT'ed modules,
but there were a few problems:
- Some packages are not installed (i.e. not in PRODUCT_PACAKGES)
but are built (i.e. in ALL_MODULES). And some of them are built in spite
that they do not have appropriate prebuilt shared library for TARGET_ARCH.
Stripping them causes "unknown format".
- Some prebuilt modules set LOCAL_MODULE_CLASS incorrectly.
Example is default.supp of external/valgrind/main, which should be ETC,
not SHARED_LIBRARY.
Both are better fixed, but I concluded that it's better to be conservative.
Bug: 4585734
Change-Id: If71723b1d76007d45b02429ea5161a8265dd5b6d
For target Java libraries, now the LOCAL_BUILT_MODULE includes both javalib.jar
and the .odex file, if dexpreopt is enabled.
These 2 files are moved to a product-specific dir in this change.
For target Java Libraries, $(intermediates) now points to the product-specific dir.
There is still a javalib.jar in the $(intermediates.COMMON) dir, which is used as dependency.
Nothing is changed for host Java libraries.
Change-Id: I2546dbb940c74537864ca002d1acb49bb731fbbc
Setting LOCAL_CERTIFICATE to "EXTERNAL" now marks an apk (either a
prebuilt or otherwise) as needing the default test key within the
system, but one that should be signed after the target_files is
produced but before sign_target_files_apks does the rest of the
signing. (We use this to ship apps on the system that are signed by
third parties, like Facebook.)
Require people who check in new prebuilts to decide what keys they
should be signed with, rather than having a fire drill every time we
go to sign a build and discover new prebuilts.
Dan Willemsen