As they can't built arm64 binaries. All of our master-based builds are
now running on macOS 11 buildbots.
Bug: 203607969
Change-Id: I24c34a8365a399fbe43629ab5a22a1d53e3429b3
This just sets up the toolchain and allows Darwin+Arm64 to be specified
as a HostCross target. These variants will not be exported to Make, or
be installed on a Soong-only build. A future CL will add support for
universal binaries using these variants.
This config is a bit stranger than the regular 64/32 multilib, as it's
two primary 64-bit configs. And on a Darwin/X86 machine, the Arm64
versions are HostCross (doesn't work on the current machines), while a
Darwin/Arm64 machine, either version works (if Rosetta is installed).
Bug: 203607969
Change-Id: Iacaed77d267773672da027cd74917e33fb1c1e94
We're now packaging llvm-windres (aosp/1870074) which can be used as a
substitute for GNU binutils' windres, but we've also removed the last
consumer of .rc files in aosp/1867048 (external/mdnsresponder/).
In the worst case, we can bring back support for .rc files but instead
process them with llvm-windres.
Bug: 203794880
Test: lunch aosp_cf_x86_64_phone-userdebug && m
Change-Id: I30a873537e004b46a87191a932d076a89463c873
Modern Xcode versions only have a single macOS SDK installed anymore, so
we don't need to iterate through our supported versions, only check
whether the current version is supported.
This also makes it so that we can specify "11" (or soon, "12") to
specify all 11.x SDKs, instead of having to update our supported list
multiple times a year. This matches previous years that had multiple
patch releases on 10.14.y, 10.15.y, etc.
Bug: 203607969
Test: build on Mac, changing the supported SDK list
Change-Id: I42715f7e8dfec811de440a435927c14c742dede9
Test: USE_BAZEL_ANALYSIS=1 m adbd
Test: Manually verified config.bzl contains various x86_host flags after
bp2build.
Test: Unit tests
Change-Id: Ie9201ea2be4cd1c6659bea088a797cedbae37403
The Android SDK has been built with Make up until now, monolithically,
then split up into several sdk-repo zip files for different purposes.
The Mac and Windows SDKs really only need to contain the platform-tools
and build-tools pieces, but due to this monolithic sdk zip, we had to
build the whole SDK first.
This adds an `android_sdk_repo_host` module that can build these
platform-tools and build-tools zips.
Bug: 187222815
Change-Id: I55809e1d7447dd65e22461f921b2b8abb6d5f822
We turned this off in local tidy flags, but didn't disable it on global
tidy builds. Let's remove this for now, since the upkeep cost is large
on it, and it also is currently crashing in some cases.
Bug: http://b/199534745
Bug: http://b/194865868
Test: WITH_TIDY=1 m
Change-Id: Ife39ab4949c5baf825efff66326b276c6a2a59f4
* Do not run expensive clang-analyzer-* checks with googletest/*,
which should be checked upstream.
Test: make WITH_TIDY=1 CLANG_ANALYZER_CHECKS=1
Bug: 198098397
Change-Id: Ic801ffa802b42d4d55ae89553073c926f9eaa351
* changes:
Fix crtend for musl static binaries
Support static_executable: true for musl builds
Use SystemSharedLibs as StaticLibs for static executables
Unlike glibc, musl does not #define __MUSL__ on the assumption that
building against musl will be done using a configure script that should
be testing for individual features rather than assuming them based on
using musl. We don't use configure-based builds, so add a local
ANDROID_HOST_MUSL macro that will be defined for all host musl builds.
Bug: 190084016
Test: m USE_HOST_MUSL=true adb
Change-Id: I44e3ffd1d727fd0ea8b69c3b074fef7e92e2be41
