Currently, passing `--wasmkit` to `build-script` also requires `--swiftpm --install-swiftpm` and all of their dependencies (at the very least Dispatch, Foundation, XCTest, Testing, llbuild, swift-build). We can conditionally switch to host SwiftPM in this case.
Introduces a new build-script flag `--test-optimize-none-with-opaque-values`
and build targets like `check-swift-optimize_none_with_opaque_values` that
runs the execution_test's while compiling them with -enable-sil-opaque-values.
This mode is quite useful while working to bring-up opaque values.
This new flag makes it easy to build Swift cross-compilation toolchains,
by disabling cross-compilation of all host tools, like the Swift
compiler and various macros, building on prior pulls #38441 and #82163.
Native compilation has more fine-grained flags like
`--build-swift-tools`, `--build-llvm`, and `--swift-testing-macros`, but
those will disable building them for _all_ platforms (with the exception
of `--build-swift-tools`, which I modified to only apply for the host,
since the initial introduction of this
`--cross-compile-build-swift-tools` flag a couple months ago), so
they're not suited for building a cross-compilation toolchain, where you
want all host tools built for the native host but not for any
cross-compilation SDKs.
Currently we are using the same versions we use to build compiler and
standard library. This is an unnecessary coupling especially when
testing the generation of backdeployed executables for macOS -- here
we have interest in being able to run the tests on previous OSes, not
the compiler itself.
To support this, add new `--darwin-test-deployment-version-<platform>`
flags to build-script, which by default take the same value as the
matching `--darwin-deployment-version-<platform>` ones.
Addresses rdar://156724078
Clang driver only passes arch-specific library paths as search paths
to the linker for WebAssembly targets but we were installing
libxml2.a under `<sysroot>/lib` without the multiarch triple. It led
to the linker not finding libxml2.a when importing FoundationXML
Due to the fact that Wasm testing targets are configured by Python `build-script` unlike `build-script-impl` for the rest of testing targets, `--lit-args` value was ignored and not recorded in these targets. These are configured as `LLVM_LIT_ARGS` in CMake.
Let's assign the `LLVM_LIT_ARGS` configuration value in Python `build-script` to handle `--lit-args` consistently for all testing targets.
Run new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support both `-wasi` and `-wasip1` triples, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
wasmswiftsdk.py: consistently apply `build_runtime_with_host_compiler`
Following up on https://github.com/swiftlang/swift/pull/83134https://github.com/swiftlang/swift/pull/82949https://github.com/swiftlang/swift/pull/82946https://github.com/swiftlang/swift/pull/82944.
With these changes I'm able to quickly build and test only Wasm Swift SDK without rebuilding the whole toolchain when latest development snapshot is installed, using this invocation:
```
./swift/utils/build-script --skip-build-benchmarks --release --skip-early-swift-driver \
--skip-build-lldb --skip-build-cmark --skip-build-llvm --skip-build-swift \
--build-runtime-with-host-compiler --build-wasm-stdlib
```
Timing on M4 MacBook Pro:
```
--- Build Script Analyzer ---
Build Percentage Build Duration (sec) Build Phase
================ ==================== ===========
43.6% 257.75 Building wasmswiftsdk
20.6% 121.91 Building wasmthreadsstdlib
20.6% 121.78 Building wasmstdlib
5.4% 32.03 Building wasmllvmruntimelibs
3.6% 21.39 Running tests for wasmthreadsstdlib
3.5% 20.91 Running tests for wasmstdlib
2.7% 15.74 Building wasilibc
0.0% 0.04 macosx-arm64-extractsymbols
0.0% 0.04 macosx-arm64-package
0.0% 0.03 merged-hosts-lipo-core
0.0% 0.03 merged-hosts-lipo
Total Duration: 591.65 seconds (9m 51s)
```
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.
