We're making an NDK API Council +1 a requirment for changes to these
files, so we need to know that all symbol files will match a given
file pattern.
Test: Changed a symbol file to foo.txt, `make ndk` failed
Test: make ndk
Bug: http://b/35870541
Change-Id: I29690fb97746ad682e57845fea3f1114cfd77598
Cleanup of some failure messages
Also, this leaves the temp directory untouched if a declared output was not created
Bug: 35562758
Test: make
Change-Id: I8ef1315af80eb327752501f12a331dbdf52ba3e9
This causes Soong to put the outputs of each genrule into a temporary
location and copy the declared outputs back to the output directory.
This gets the process closer to having an actual sandbox.
Bug: 35562758
Test: make
Change-Id: I8048fbf1a3899a86fb99d71b60669b6633b07b3e
This is still fairly simplistic, but good enough to test some build
system changes.
Bug: 33381544
Test: run, inspect output
Change-Id: Ia5c19570493116dca01cb65605cdf20becf8c1d0
This CL fixes a bug with how Soong builds the install path for native
tests. Tests are installed in /data/nativetest* by default, but the
logic was wrongly redirecting sanitized versions to
/data/asan/system/nativetest*. With this fix, they are correctly
redirected to /data/asan/data/nativetest* instead.
Bug: 37942061
Test: lunch marlin_asan-userdebug && \
SANITIZE_TARGET="address" m -j70 \
# nativetests are generated in /data/asan/data/nativetest*
Change-Id: I0c132af5d443151c44219d231770049fddf79bbe
Also filter out -Wl,--no-undefined for all host sanitizers, not just ASan.
UBSan on host defaults to no-trap (i.e. diagnostic mode), and that requires
the runtime library and runs into the same problem with undefined symbols as ASan.
Bug: 34719251
Test: Misc_undefined: ["integer"] on a soong target
Change-Id: I1fb4781f663a11f5f427d50c0bf9beb8e181cd5e
Merged-In: I1fb4781f663a11f5f427d50c0bf9beb8e181cd5e
(cherry picked from commit fe9bc1dccb)
This doesn't catch all the possible causes of timeouts,
(like if Ninja is only partially stuck or if Kati is stuck)
but it should clarify some causes of stuckness
Bug: 62065855
Test: m -j showcommands NINJA_HEARTBEAT_INTERVAL=500ms
Change-Id: I73a792ae91873b19d7b336166a2d47f37c549906
I removed *.txt from the installclean list yesterday, but it turns out
that android-info.txt being removed was the only thing triggering
system.prop to be rebuilt on the incremental build servers. So continue
android-info.txt so that the version information in system.prop is
correct.
I'll follow this up with a more complicated change to make the
system.prop generation depend on the build number/versions more
directly, but that's a more complicated change since we need to change
how the build number file is written.
Bug: 62252890
Test: m ...intermediates/system.prop; m installclean; m ...intermediates/system.prop
Change-Id: I25dd8ddd99f7b2c927a8cbfb7f1aca1dd3e82a82
For *.ini/*.txt files we should be recreating them as the instructions
change, so we shouldn't need to remove them. The biggest reason to
remove them is that the auto-installclean was removing
$PRODUCT_OUT/build_fingerprint.txt just after Kati wrote it out, causing
the fingerprint to be blank on builds where the auto installclean code
ran.
There's no reference to xlb in our tree, and it's been around since the
beginning of git history, so remove it.
Bug: 62224537
Test: lunch aosp_arm-eng; m nothing;
lunch aosp_arm-userdebug; m -j nothing;
check out/target/product/generic/build_fingerprint.txt
Change-Id: Id391af5c7d95ea78e4e68fae294d8295fccb1964
Some of ART tests fail to mmap memory unless
LibartImgDeviceBaseAddress() is further lowered.
Test: booted MIPS32R2 in QEMU
Test: booted MIPS64 (with 2nd arch MIPS32R6) in QEMU
Test: test-art-target-gtest
Test: testrunner.py --target --optimizing
Test: repeat all of the above in configurations
ART_READ_BARRIER_TYPE=TABLELOOKUP,
ART_USE_READ_BARRIER=false
Test: repeat the above tests on CI20
Change-Id: I48cd9d8074e07073cc6abb2153660e00017b9e6b
By default, the Android build enforces an OpenJDK 8 toolchain,
whose name contains the strings "openjdk" and "1.8".
After this CL, the check can be changed to enforce a toolchain
name starting with "9" and without the need for "openjdk" having
to occur in the name.
This experimental new check can be enabled by running:
export EXPERIMENTAL_USE_OPENJDK9=true
To switch back to the standard check, run:
unset EXPERIMENTAL_USE_OPENJDK9
Test: make ANDROID_COMPILE_WITH_JACK=false checkbuild tests \
&& make checkbuild tests
(with OpenJDK 8u45 toolchain on the PATH)
Test: make EXPERIMENTAL_USE_OPENJDK9=true \
ANDROID_COMPILE_WITH_JACK=false checkbuild
(with jdk 9-ea+170 toolchain on the PATH)
Bug: 38177295
Change-Id: I75de3e23fe0b7f41eb6dd3f55dadd3fa3c3383bd
