1) Updates the LOCAL_COMPATIBILITY_SUITE line to allow for a
testcase to belong to multiple suites.
2) Building testcases no longer fails if
COMPATIBILITY_TESTCASES_OUT_<suite> is not defined. This
testcase will just not output to that directory.
This will be utilized by the device-tests and general-tests
suites that don't require any extra output besides the common
testcase directory.
Bug: 35394351
Test: 1) Added multiple *TS testcases to cts & vts and verified they
ended up in the common directory and each suite's testcase
directory. Specifically tested CtsSplitApp to ensure the
split usecase still works as well.
2) Added a CTS testcase to the device-tests suite, built
device-tests and verified the cts/android-cts/testcases
copy was not produced.
Change-Id: Ic4c4e87e62be4fc0c5e394d88cc359518346dffa
Stop blaming base_rules.mk, put the module makefile at the beginning
of the line. That way scripts like warn.py can parse this better.
Test: multiproduct_kati, grep logs
Change-Id: I5e6844097b44e47b8126159c1760b7524134310d
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
The init.rc path selection uses the same partition_tag detection to
select an installation partition. So make sure that we always set
partition_tag even if we've been given an explicit module path.
Bug: 35314904
Test: set proprietary: true to Soong module with an init rc, verify
that was the only change to build-aosp_arm64.ninja
Change-Id: Ic6ffd7a5177959db96a34a24896b242ee5b09e41
Instead of dumping all *TS testcases into the common testcase
directory directly, place them all in their own subdirectory.
Bug: 35153177
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: I22a768dba58d40be1e61885534fb813e7ff08c99
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
When building test modules, dependencies added by the test modules get
build but don't get included in the packaged tests .zip file.
When packaging modules into a .zip file, this patch includes the modules
explicitly listed as a dependency in LOCAL_REQUIRED_MODULES for the
requested modules to package.
If these LOCAL_REQUIRED_MODULES dependencies are not used in the base
system image, they were build as part of the "tests" target but weree
not included in the package nor in the system image. This patch includes
those modules, making it easier to define dependencies of a test
module in the Android.mk file that defined said module, instead of
requiring to re-list all the dependent modules when packaging test
modules.
Bug: 27348226
Change-Id: Ic6f60cf2916b3fae0fa39f84aee8a4f440af9539
This can be used to ship source data as test artifacts next to native
tests. It works for both local builds and the test bundles using
package_modules.mk.
You just specify a file list relative to the local directory, and those
files will be copied next to the executable under
/data/nativetest*/<module>/...:
LOCAL_MODULE := mytest
LOCAL_TEST_DATA := data/file1 file2
/data/nativetest/mytest/mytest
/data/nativetest/mytest/data/file1
/data/nativetest/mytest/file2
If the data is in another directory, you may also specify a different
prefix for the source files:
LOCAL_TEST_DATA := external/skia:resources/f.xml
/data/nativetest/skia_test/resources/f.xml
And there's a new convenience macro to find a list of files in this
format:
LOCAL_TEST_DATA := $(call find-test-data-in-subdirs,external/skia,"*.xml",resources)
I'll expand this to native benchmarks and fuzz tests in a later change,
since they don't have their own module classes yet.
Bug: 30564705
Test: m -j minikin_tests; ls $OUT/data/nativetest*/minikin_tests
Test: m -j continuous_native_tests dist; zipinfo -1 out/dist/*continuous_native_tests*.zip
Change-Id: Ic76a7b62e7f567f259c4ab1510ee97d26600ba9a
The PDK uses pattern rules in order to install files from the PDK. When
those files already have build rules, the explicit rules override the
pattern rules, and everything works. But because Make (and Kati) doesn't
attempt to clean the file paths, if one of the rules has a redundant /,
we'll export two ninja rules, and ninja will error out with a dupbuild
error.
The PDK pattern rules are clean, but the explicit notice file creation
was not, it was always adding a double // in between NOTICE_FILES/src
and the module path.
Some modules were also setting a LOCAL_MODULE_PATH with a trailing /,
which is redundant, and also hits the above problem. Instead of fixing
all of the modules, just strip a trailing / from my_module_path.
Bug: 33451638
Test: Build with a PDK
Change-Id: Iff3e98fd191ea90626b9b89f179537e8a75f5ef2
Previously, clang-host would build the clang module for 32-bit and
64-bit for the host and for windows. Make clang-host only compile
for host, and add clang-host-cross for windows. Also add targets
that only build 32-bit or 64-bit: clang-host32, clang-host64,
clang-host-cross32, clang-host-cross64, clang-target32, and
clang-target64.
Test: inspect build.ninja
Change-Id: I7676f9497dfc852f2a0255dda8da06c88eec0db8
Add BOARD_VNDK_VERSION and LOCAL_USE_VNDK to specify the version of the
VNDK that will be used globally, and whether to use the VNDK on a module
basis.
If the board is using the VNDK:
* LOCAL_COPY_HEADERS may only be used by modules defining LOCAL_USE_VNDK
* LOCAL_USE_VNDK modules will compile against the NDK headers and stub
libraries, but continue to use the platform libc++.
* LOCAL_USE_VNDK modules will not have the global includes like
system/core/include, but it will use device-specific kernel headers.
This change does not attempt to enforce any linking constraints, that
will come in a later patch.
Test: out/build-aosp_arm.ninja is identical before/after
Change-Id: Icce65d4974f085093d500b5b2516983788fe2905
Runtime resource overlay is a bare APK with just the overlaid
resources. There is no need for additional subdir.
See http://go/sku-colors.
Bug: 31692079
Change-Id: Iff3d58f941e764a7be3ec04cafeefd592bd8b944
The toc optimization had been disabled for host builds to ensure that
the timestamp of the final binary changed whenever its implementation
changed, in order to support rerunning host tools that were modified
during incremental builds. However, only the final install rule must be
re-run to update the timestamp, and not the link rule.
Update the shared library install dependencies to use normal
dependencies instead of order-only dependencies for host modules, and
then enable the the toc optimization for host modules. If the
implementation of a library changes it will be reinstalled, and
libraries or binaries that depend on it will also be reinstalled.
Bug: 26015464
Test: m -j; touch art/disassembler/disassembler_x86.cc; m -j, verify
out/host/linux-x86/bin/oatdump is updated
Change-Id: I0a14decc1994eb55ad269d841943aef66e320c63
Move extra module dependencies like symlinks from dependencies of
$(my_register_name) to $(my_all_targets), and make $(my_register_name)
and other convenience phony modules depend on $(my_all_targets). Move
$(LOCAL_MODULE)-host/-target to depend on $(my_all_targets) instead of
directly depending on the built and installed modules.
Change-Id: I3b093986db7a1bff118f1f2482275f0997a98fb6
Make symlinks an order-only dependency of the module name phony target
so that they get installed with make module or make MODULES-IN-path.
Test: mmma -j art/dalvikvm, remove symlink in $OUT and retry
Change-Id: Iae472a1c8fa1e8386cc9556cfe819bd4fca99428
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>
We supported de-duplicating LOCAL_INIT_RC across multiple architecture
variants in a single module definition, but that didn't work if the
module was defined with two different BUILD_PREBUILT definitions. That's
how we're exporting modules from Soong to Make.
Change-Id: Ifc93b15ef78ea3d8e78005d428a3ec57d7e414e8
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
Specifying LOCAL_MODULE_SYMLINKS will create symlinks to the installed
module in the same directory.
Change-Id: Idecb2b75f0c9999eb000eed9a79a989244ccf6c2
am: 58b7c1c744
* commit '58b7c1c744aa49fb0686848b281ae75c2485f420':
Add LOCAL_LOGTAGS_FILES that prebuilts can use
Change-Id: I76a6077c3945463a5b52fb8a4f5146a2590de716
Soong modules can define logtags files that need to be combined into
/system/etc/event-log-tags, so add a new LOCAL_LOGTAGS_FILES variable
that can be used to specify *.logtags file outside of LOCAL_SRC_FILES.
Bug: 28989759
Change-Id: I53c5d396dfb7c6006806758f351eb5cdde90fe74
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
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)
Now that copy-file-to-target doesn't use acp, nothing in the acp build
path uses acp, so we don't need to special case it to prevent loops.
Change-Id: I12810c1b064d0c03135a80077a76bc4c9cc18b24
And everything special-cased on that. Add a warning if USE_NINJA is
set to let users know that it no longer changes anything.
Change-Id: Ib8739151fe26ea6bf8f76b7ac2b8f4097dab0b47
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
It's a valid situation for all three of LOCAL_INIT_RC, LOCAL_INIT_RC_32,
and LOCAL_INIT_RC_64 to be used.
Bug: 26773181
Change-Id: If9661f93b1823279075fc3d55195f7a939e01b6f
So that you can have LOCAL_COMPATIBILITY_SUPPORT_FILES generated in the
out directory.
Change-Id: I3e011fc3db5de170f7befcb12841d230283671a6
(cherry picked from commit c3e4b2f390)
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
