We currently use static libraries without any source files to represent
header libraries, but Soong actually has cc_library_headers. So to
export those in a separate namespace from static libraries, implement
them in Make as well.
This also adds a nice pretty-warning / pretty-error macro that can be
used to print out standard warning messages pointing to the real source
file having the problem.
Test: Use a header library exported by Soong in a Make module
Change-Id: I3486539e247524cb82a20620745fc7be03014e14
Aggregates the different *TS testcases into two common folders,
one under each the host and product hierarchies.
Bug: 34715822
Test: `make cts -j` and checked the contents of both:
out/host/linux-x86/testcases/ &
out/host/linux-x86/cts/android-cts/testcases/
Change-Id: I7d5201998ddcb011ecc687c272a0d0a36da248b7
Also mark these variables as readonly so that later Android.mk cannot
change them.
Bug: 33607778
Test: build/tools/kati_all_products.sh -j12
Change-Id: I5f9a4df02bfdfd56549728f074bbb3fc251edb3d
There are no users left, so remove all of this.
Test: lunch aosp_arm-eng; m -j native
Test: build/tools/kati_all_products.sh on aosp and internal master
Change-Id: I32f5c8b470a43dd203d7e20c192167630e4e6888
Native coverage is enabled by setting NATIVE_COVERAGE to true
and specifying a list of paths in the COVERAGE_PATHS
environment variable. Files are exported to a zip file in the
target out directory.
Change-Id: I66a2ddd88e849bec1cc0cdae1b51fe18a007e2c3
HOST_PREFER_32_BIT was used during the switch to 64-bit host tools to
keep the SDK building as 32-bit, but is never set any more.
Change-Id: I874f89c7d1e9cd8c9d4c879048d81a4362ce4dce
This was printing all of the Soong modules in addition to the modules
defined in the ONE_SHOT_MAKEFILE. So replicate what we did with
MODULES-IN-* with GET-INSTALL-PATH-IN-* and update all the users.
Bug: 30191725
Change-Id: Ib1e4bf00f64d7a3e8cd91f44eaf1ff82fdfbf162
AUX is a new class, similar to TARGET
While TARGET defines toolchain for Application Processors
AUX is defining toolchains for arbitrary utility cores (DSPs, GPUs,
MCUs, etc). This allows building of non-android sources as part
of Android tree and avoid using prebuilts if source code is avaliable
Bug: 29635686
Change-Id: Ie755ea054b16c3e86369f5fb2ba6eb0b384af77f
Signed-off-by: Alexey Polyudov <apolyudov@google.com>
Build error when LOCAL_PROPRIETARY_MODULE, LOCAL_PRIVILEGED_MODULE,
and LOCAL_MULTILIB := 32 are set for a module in 64-bit build.
The patch adds path definition for
$(TARGET_2ND_ARCH_VAR_PREFIX)TARGET_OUT_VENDOR_APPS_PRIVILEGED
Change-Id: I2fe0c0f28fb7e4a27defd3a1b04f84c8b296294f
Fix the directory for secondary-architecture libraries under
sanitization. These incorrectly wrote into vendor/lib instead
of data/vendor/lib.
Bug: 29498013
Change-Id: Iee08422a1f7ad42cbe71a322347e98cb74e3ef7f
For AB devices, support flashing two system partitions for factory use.
The normal system image on one partition, but without dex preopt. And a
system_other image that just contains the odex files. The dex files will
not be stripped out of the system image, in case the second system
partition is wiped.
Setting BOARD_USES_SYSTEM_OTHER_ODEX := true in the BoardConfig.mk
enables this behavior.
One can control which directories are placed in system_other by the
SYSTEM_OTHER_ODEX_FILTER configuration variable. Currently we default
to only copying only app and priv-app odexs.
Bug: 29278988
Change-Id: I7f4e87da919e7dc6a89fd8c668193cd4e98631bc
Standardize symlinking /system/vendor -> /vendor for aosp_* devices,
since some /vendor binaries still use /system/vendor/... paths.
Support using a prebuilt vendor image and including it into all the
normal packaging steps.
Bug: 28987532
Change-Id: I27040e8a8d1df0777e16cd1e3c3a9f1b28695e96
am: 323396993c
* commit '323396993c6651b4b98974df9e9d53118f27a840':
Fix mm and mmm in Android.bp directories
Change-Id: I95d6bde7a0ea72b47779f1a5b0577ff423524b6f
mm and mmm were not parsing out/soong/Android.mk, so they were ignoring
all modules defined in an Android.bp file. Always include
out/soong/Android.mk when ONE_SHOT_MAKEFILE is set, and convert the mm
and mmm functions to build MODULES-IN-$DIR instead of all_modules so
that only the subset of modules defined in out/soong/Android.mk for the
requested directory are built.
Bug: 28986194
Change-Id: I6e1ff8cacfc668a4154a0d5937450db840bb7a6b
These are all either recently unused due to the removal of CFLAGS/etc,
or have been exported by Soong and are no longer necessary.
Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
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
A blank USE_CLANG_PLATFORM_BUILD= on the command line for make causes
confusion between make and kati. make ignores writes to variables set
on the command line, so envsetup.mk cannot set it to true,
USE_CLANG_PLATFORM_BUILD is still empty in soong.mk, and soong.variables
gets DeviceUsesClang: false. kati gets USE_CLANG_PLATFORM_BUILD= in its
environment instead of on its command line, so envsetup.mk when parsed
by kati sets USE_CLANG_PLATFORM_BUILD=true.
Error out early if USE_CLANG_PLATFORM_BUILD is not true or false after
attempting to set it to true if it is empty.
Change-Id: I0e2731315711db9a6ac6ea2bf49c88bccacd35f7
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)
1. Combined ~10 calls to the make build system to only one.
We added a phony target "dump-many-vars" to the build system to dump
"<var>=<value>" pairs. We then store the pairs as shell variables.
With this cache get_build_var/get_abs_build_var can just return
the shell variables instead of querying the build system.
2. Prune .git when we search for AndroidProduct.mks.
In internal source tree lunch time was reduced from ~15s to ~1.5s.
Bug: 27429759
(cherry picked from commit 08800fd905)
Change-Id: I862a0ec3c1aae97c552054dacec133e857042edf
1. Combined ~10 calls to the make build system to only one.
We added a phony target "dump-many-vars" to the build system to dump
"<var>=<value>" pairs. We then store the pairs as shell variables.
With this cache get_build_var/get_abs_build_var can just return
the shell variables instead of querying the build system.
2. Prune .git when we search for AndroidProduct.mks.
In internal source tree lunch time was reduced from ~15s to ~1.5s.
Bug: 27429759
Change-Id: I24e88598f6fab598ef26518885fd5e86e71a772d
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
(cherry picked from commit 9ecbf83259)
Change-Id: Iab2d36e20d7002568c3534e7781e9ac8ab21a4a9
These have been using SHARED_LIBRARIES, but aren't elf shared libraries.
Continue installing them to /system/lib[64], but do not apply any other
normal shared library logic to them.
(cherry picked from commit c6e194ffad)
Change-Id: I0041650af92cd8063ca33215010d5eff514a89bc
These have been using SHARED_LIBRARIES, but aren't elf shared libraries.
Continue installing them to /system/lib[64], but do not apply any other
normal shared library logic to them.
Change-Id: I3055ff86bb7b116c7107c41578ed6f0f304b1cf1
This is mostly the same as the existing 2ND_HOST / HOST_CROSS support.
The interesting thing I did here was make x86 the 'first' architecture,
and x86_64 the second. This way LOCAL_MULTILIB := first defaults to
32-bit windows modules.
windows-x86/bin <- defaults to 32-bit executables
windows-x86/lib <- 32-bit libraries, like before
windows-x86/lib64 <- 64-bit libraries
windows-x86/obj <- 32-bit intermediates
windows-x86/obj64 <- 64-bit intermediates
Then modules are registered with the names:
host_cross_liblog <- 32-bit, like before
host_cross_liblog_64 <- 64-bit
Bug: 26957718
Change-Id: I9f119411acb43e973ec1e6bca3c1dc291c91556c
Dan Willemsen