Disable Python, to make the LLDB executables more portable,
so they don't rely on whatever version might have been installed on
the GitHub Actions runner.
Relevant changes since 16.0.6 are:
- Improve Address Sanitizer on i686 mingw
- Improve handling of X86 Intel assembly syntax
- Fix using std::wcout/wcin/wcerr with streams configured in wide mode
- Improve handling of the .arch and .arch_extension assembly directives
on aarch64
- Support the --temp-prefix (ignored) and --no-leading-underscore
options in llvm-dlltool
- Make lld warn about too narrow pseudo relocations, simplifying finding
issues that otherwise only show up at runtime
- Improved the tests, making compiler-rt, libcxxabi and libunwind tests
pass in mingw configurations
Versions 4.3 and above only come packaged as .tar.gz and .tar.lz,
and the lzip decompressor is less commonly readily available, thus
switch back to the .tar.gz format.
Ubuntu 20.04 comes with CMake 3.16, so there's no need to install
a custom version of CMake for now (for LLVM 16.x; LLVM 17 will have
the requirement raised to CMake 3.20 though).
Also drop the workaround for git issues in the old version in
Ubuntu 18.04.
The latest releases that are built on GitHub Actions without
docker are based on Ubuntu 20.04 anyway, so there's less demand
for building this with an older version for the sake of
compatibility of the built binaries. For users using the built
docker image as such, having it based on a newer base distribution
is beneficial.
Older macOS versions (macOS 12.2 at least) don't support this
option, while newer macOS versions do support it (macOS 12.6).
The solution is based on https://stackoverflow.com/a/1116890/3115956,
but simplified for this usecase.
These tests should now all pass on both architectures; the
check-asan tests for the static CRT are skipped automatically,
the failures in check-interception have been fixed by compiling
the tests with the --large-address-aware flag, and the
check-asan-dynamic tests on i686 have been fixed - all by
Alvin Wong.
Currently, there's no practical difference if the spelling of this
triple is inconsistent, but if we'd enable e.g. the per-target
runtime directories, the exact spelling does make a difference.
For consistency, pass CMAKE_C_COMPILER_TARGET with the exact right
spelling everywhere.