build-script: allow `--test-wasm-stdlib` without `--build-wasm-stdlib`
This allows testing Wasm stdlib without fully rebuilding WASI sysroot and stdlib, while changes to stdlib itself are still detected by ninja as dependencies and are built incrementally, which is great for local builds.
Install static XCTest library and its Swift module files in the following
directory structure:
```
usr/lib/swift_static/wasi/libXCTest.a
usr/lib/swift_static/wasi/XCTest.swiftmodule
```
wasm-run.py: consistent `wasmkit` path with `build_runtime_with_host_compiler`
When passing `--build-runtime-with-host-compiler` there's no such executable `wasmkit-cli` in the host toolchain, where it's named `wasmkit` when installed. Let's make that consistent to make it work in both cases.
Fix type error in `should_test_executable`:
```
reportIncompatibleMethodOverride: Method "should_test_executable" overrides class "WasmStdlib" in an incompatible manner
Return type mismatch: base method returns type "Literal[True]", override returns type "Literal[False]"
"Literal[False]" is not assignable to type "Literal[True]"
```
This allows testing Wasm stdlib without rebuilding WASI sysroot and stdlib, while some changes are still detected by ninja as dependencies and are rebuilt, which is great for local incremental builds.
We should eventually split these, but for now SWIFT_COMPILER_VERSION
matches SWIFT_TOOLCHAIN_VERSION when it's actually set. Just use it in
preference to SWIFT_TOOLCHAIN_VERSION.
This allows quickly building WASI sysroot when `--skip-build-llvm --skip-build-swift --build-runtime-with-host-compiler --build-wasm-stdlib` combination of options is passed to `build-script`.
This allows quickly building `WasmLLVMRuntimeLibs` product with the host toolchain (usually Swift nightly development snapshot toolchain) when `--skip-build-llvm --skip-build-swift --build-runtime-with-host-compiler` combination of options is passed to `build-script`.
This allows quickly building WASI-libc and Swift stdlib with WASI when `--skip-build-llvm --skip-build-swift --build-runtime-with-host-compiler` combination of options is passed to `build-script`.
This allows skipping the installation for WasmKit when building it, which is consistent to how other products are handled by `build-script`, where they have separate `--install` options. Existing behavior is preserved: passing `--wasmkit` alone will install it, but now `--wasmkit --install-wasmkit false` will skip its installation step.
With the addition of libxml2 and Foundation builds, lack of `ignore_extra_cmake_options=True` regressed macOS builds, where `extra-cmake-options` from macOS presets are picked up, overriding required `CMAKE_CXX_FLAGS` that need to be used for these products instead.
Current use of `print` without `flush=True` outputs these logs at the end of a `build-script` run, after the supposedly final `--- Build Script Analyzer ---` output, which is quite confusing when reading logs.
This allows skipping the installation step and only building WasmKit, which is consistent to how other products are handled by `build-script`, where they have separate `--install` options. Existing behavior is preserved, where passing `--wasmkit` alone will install it, but now `--wasmkit --install-wasmkit false` will skip its installation step.
For small local incremental builds that require WasmKit it's faster to build WasmKit with the host toolchain instead of waiting for a full bootstrap build to complete.
If things crash very early on, build-script tries to divide by zero when
computing the percent time spent in each project because the build time
is zero. While this is a failure state, all it does is add more output
to the crashing stack trace.
The tests broke on the community Android CI since #82325, and I just
noticed the install issue when cross-compiling Testing with a
freshly-built compiler, which I'd never done before. Also, fix the NDK
path shown in the CMake output.
The build support Python libraries assume by default that if we do not
supply a Swift toolchain path, we can find clang in the installed
toolchain path: i.e., the clang that we just built. However, possibly
during bootstrap, we may not have a preexisting Swift compiler but still
want to use the clang on the platform that is already installed.
build-script already gives us native-clang-tools-path. Here, we plumb
this through to the relevant Python modules. If the
native-clang-tools-path is not specified, we use the
install_toolchain_path, just like native_toolchain_path, and the
existing behavior is effectively unchanged. If we do specify a
native-clang-tools-path, then we return it to ensure that we properly
refer to the clang that lives there instead of always defaulting to the
just-built clang.
Added optional `ignore_extra_cmake_options` to `cmake_product.py`, existing behavior is preserved with the default argument value set to `False`.
Passed `ignore_extra_cmake_options=True` in `wasisysroot.py`. This allows libc++ for WASI to be built correctly with `-fno-exceptions` in presence of `extra-cmake-options` in macOS presets (which are absent in Linux presets).
Otherwise the build will fail if we pass `--no-llvm-include-tests` or we
set directly `LLVM_INCLUDE_TESTS` directly to `FALSE`/`OFF`
Addresses rdar://153562845
While LLVM cannot be completely disabled when Swift or LLDB are built, we should still allow skipping LLVM configuration and build steps when Swift and LLDB are not built. This can happen, for example, when `build-script` user wants an ad-hoc incremental build with `--skip-build-swift` and `--skip-build-lldb` for products that don't depend on LLVM and Swift, or if LLVM and Swift were already configured and built in previous `build-script` invocations.
Since 5f2b0022d1, swift-testing is being
compiled with WMO, which removes some of inter-object references in
object files by DCE. The inter-object reference removal revealed a
long-standing issue that the runtime metadata sections of objects in an
archive are not always included in the final binary if symbols from
those objects are not referenced anywhere. To force including all
metadata sections in the final binary, we have to emit everything in a
single object file when building the archive.
This issue happens only for Wasm SDK, which ships swift-testing as a
static archive.
Passes the value of the environment variable `TOOLCHAIN_VERSION` through
to Swift's `SWIFT_TOOLCHAIN_VERSION` for use in eg.
`-print-target-info` (and some day, `--version`).
