forked from swiftlang/swift
-
Notifications
You must be signed in to change notification settings - Fork 30
Deprecate toolchain installation #5604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
kateinoigakukun
added a commit
to swiftwasm/swiftwasm-build
that referenced
this issue
Feb 28, 2025
kateinoigakukun
added a commit
to swiftwasm/swiftwasm-build
that referenced
this issue
Feb 28, 2025
It might be a good time to move the responsibility for the SDK installation from carton to the user. It's now much easier than toolchain installation. Or might be good time to archive carton by moving "bundling" and "test runner" features to JavaScriptKit as they are almost only for JS host platforms. |
1 task
kateinoigakukun
added a commit
to kateinoigakukun/swift-package-manager
that referenced
this issue
Apr 8, 2025
This change removes the hardcoded path derivation for the WASI sysroot from the `SwiftSDK.deriveTargetSwiftSDK` method. The previous implementation assumed there is $TOOLCHAIN_ROOT/share/wasi-sysroot when `--triple wasm32-unknown-wasi` is passed, but this is no longer the case with the [deprecation of the Wasm toolchain installation](swiftwasm/swift#5604) in favor of Swift SDKs.
MaxDesiatov
pushed a commit
to swiftlang/swift-package-manager
that referenced
this issue
Apr 9, 2025
Remove hardcoded WASI sysroot path derivation just for wasi-sysroot embedded in toolchains ### Motivation: The previous implementation assumed there is $TOOLCHAIN_ROOT/share/wasi-sysroot when `--triple wasm32-unknown-wasi` is passed, but this is no longer the case with the [deprecation of the Wasm toolchain installation](swiftwasm/swift#5604) in favor of Swift SDKs. Due to this unnecessary branch, when `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--swift-sdk` is just ignored: #8465 ### Modifications: This change removes the hardcoded path derivation for the WASI sysroot from the `SwiftSDK.deriveTargetSwiftSDK` method. ### Result: When `--triple wasm32-unknown-wasi` is passed without `--swift-sdk`, no user visible change and they will keep getting the following: ``` error: emit-module command failed with exit code 1 (use -v to see invocation) <unknown>:0: warning: libc not found for 'wasm32-unknown-wasi'; C stdlib may be unavailable <unknown>:0: error: unable to load standard library for target 'wasm32-unknown-wasi' ``` When `--triple wasm32-unknown-wasi` is passed together with `--swift-sdk`, `--triple` is ignored and `--swift-sdk` is respected.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Motivation
We now have Swift SDK, and it's going to be the default recommended installation way for its standard.
Maintaining two different installation methods costs a lot, and removing toolchain builds and only maintaining SDK builds allows us a much simpler build workflow and saves CI costs.
Outcome
Reducing build variants allows:
Steps
Install SDK instead of toolchain in the carton auto installerRename release tag convention to use the same tag name with the upstreamThe reason why we included-wasm-
part in our tag was just to distinguish toolchain versions of ours and upstream's in swiftenv, so we no longer need to include it. Let's just align with the upstream to make things simpler.The text was updated successfully, but these errors were encountered: