Use WasmKit by default for Wasm triples in toolsets #8668
Conversation
As WasmKit is included in recent development snapshots of the swift.org toolchain, we should select it as a default debugger and test runner when a Wasm triple is selected. User toolsets can still override it if needed through toolset merging algorithm described in SE-0387.
MaxDesiatov
requested review from
dschaefer2,
jakepetroules and
shawnhyam
as code owners
MaxDesiatov
requested review from
bripeticca,
owenv and
plemarquand
as code owners
MaxDesiatov
requested review from
bkhouri,
cmcgee1024 and
daveyc123
as code owners
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test windows |
1 similar comment
|
@swift-ci test windows |
|
@swift-ci please test self hosted windows |
|
I think it would be nice if we can generalize it by introducing a way to express a toolchain binary path in toolset.json like |
Agreed. We need to stop hardcoding so much stuff. We need to allow for someone to come along and change these things without having to put up a PR. |
As I've mentioned in the PR description, if you need to override things you can just apply your own toolset on top of the default toolset, which is the mechanism I've explicitly described in the Swift SDKs proposal foreseeing this use case. You don't need any PR to change or override this for your own needs. We're only providing a default here. What's hardcoded here is the toolchain default. Since WasmKit ships with the toolchain, it's toolchain's job to know it is there and available. If it shipped within a Swift SDK instead, then we would specify it in the Swift SDK. Since Swift SDK has no control over the toolchain, it's natural for the toolchain stuff to be hardcoded in the toolchain itself. It's no different from Clang hardcoding |
This became a required parameter in swiftlang/swift-package-manager#8668, which can be easily computed, since the host toolchain in practice is always available when `SwiftSDKBundleStore` is initialized.
jakepetroules
left a comment
jakepetroules
left a comment
There was a problem hiding this comment.
Nice, this will be a great improvement to the out-of-the-box experience for using Wasm.
This became a required parameter in swiftlang/swift-package-manager#8668, which can be easily computed, since the host toolchain in practice is always available when `SwiftSDKBundleStore` is initialized.
This became a required parameter in swiftlang/swift-package-manager#8668, which can be easily computed, since the host toolchain in practice is always available when `SwiftSDKBundleStore` is initialized.
Cherry-pick of #8668, merged as 02fe923 **Explanation**: As [WasmKit](https://github.com/swiftwasm/WasmKit) is included in recent development snapshots of the swift.org toolchain, we should select it as a default debugger and test runner when a Wasm triple is selected. User toolsets can still override it if needed through toolset merging algorithm described in [SE-0387](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0387-cross-compilation-destinations.md). This allows `swift run` and `swift test` to delegate to WasmKit when cross-compiling for any Wasm triple. **Scope**: Limited to cross-compilation. **Risk**: Low due to limited scope and added test coverage. **Testing**: Add new automated test cases, manual testing with Wasm products. **Issue**: rdar://150382758 **Reviewer**: @kateinoigakukun @jakepetroules
As WasmKit is included in recent development snapshots of the swift.org toolchain, we should select it as a default debugger and test runner when a Wasm triple is selected. User toolsets can still override it if needed through toolset merging algorithm described in SE-0387.
This allows
swift runandswift testto delegate to WasmKit when cross-compiling for any Wasm triple.rdar://150382758