-
Notifications
You must be signed in to change notification settings - Fork 208
Start renaming preview1 to p1 and preview2 to p2 #386
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
Start renaming preview1 to p1 and preview2 to p2 #386
Conversation
I'll note that I'm opening this as a draft here because WebAssembly/wasi-libc#478 should land first. In the meantime I've updated the submodule in this PR to point at my fork of wasi-libc, which should not land in this repository (it's just here for testing in CI and showing what this will look like) |
This commit is a reflection of WebAssembly/wasi-libc#478 into this repository where a few changes are happening: * A new `wasm32-wasip1` sysroot is prepared matching `wasm32-wasi` * A new `wasm32-wasip1-threads` sysroot is prepared matching `wasm32-wasi-threads` * The `wasm32-wasi-preview2` target is renamed `wasm32-wasip2` I've done a bit of makefile refactoring to deduplicate things a bit now that there's a number of targets being built. The long-term goal would be to remove the `wasm32-wasi` and `wasm32-wasip1-threads` targets, but that's not proposed just yet at this time.
36499ca
to
46a5ce1
Compare
With WebAssembly/wasi-libc#478 now landed I've updated this to the official submodule and this is no longer a draft. |
Makefile
Outdated
# Install clang-provided headers. | ||
cp -R $(ROOT_DIR)/build/llvm/lib/clang $(BUILD_PREFIX)/lib/ | ||
cp -R $(BUILD_PREFIX)/lib/clang/17/lib/wasi $(BUILD_PREFIX)/lib/clang/17/lib/wasip1 | ||
cp -R $(BUILD_PREFIX)/lib/clang/17/lib/wasi $(BUILD_PREFIX)/lib/clang/17/lib/wasip2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can these use $(CLANG_VERSION)
instead of hard-coding 17
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes indeed! I didn't look hard enough to find that.
do you mean wasm32-wasi-threads? |
…83199) - **Explanation**: Renames the WebAssembly target triple from `wasm32-unknown-wasi` to `wasm32-unknown-wasip1` to align with the broader WebAssembly ecosystem's naming conventions. It's important to include this in 6.2, which is going to be the first stable release of Swift SDK for Wasm, so that we won't introduce a breaking triple change in the stable version series later. The WebAssembly ecosystem has been migrating from the generic wasi target name to more explicit version-specific names like `wasip1` and `wasip2`. This change has been adopted across multiple toolchains and language ecosystems: - Rust: Renamed `wasm32-wasi` to `wasm32-wasip1` (rust-lang/compiler-team#607) - wasi-sdk: Renamed `wasm32-wasi` to `wasm32-wasip1` (WebAssembly/wasi-sdk#386) - Go: Already uses `wasip1` naming convention (golang/go#58141) The "p1" suffix explicitly indicates WASI Preview 1, which helps distinguish it from the newer WASI Preview 2 (wasip2) and provides clarity about which version of the WASI specification is being targeted. Also we already use `wasm32-unknown-wasip1` for Embedded WASI target, and having different names for Embedded and non-Embedded is confusing users. - **Scope**: Narrow, only affects Wasm Swift SDK. - **Original PRs**: #83167 - **Risk**: Low, just a change to Wasm Swift SDK - **Testing**: CI. - **Reviewers**: @MaxDesiatov
This commit is a reflection of WebAssembly/wasi-libc#478 into this repository where a few changes are happening:
wasm32-wasip1
sysroot is prepared matchingwasm32-wasi
wasm32-wasip1-threads
sysroot is prepared matchingwasm32-wasi-threads
wasm32-wasi-preview2
target is renamedwasm32-wasip2
I've done a bit of makefile refactoring to deduplicate things a bit now that there's a number of targets being built.
The long-term goal would be to remove the
wasm32-wasi
andwasm32-wasip1-threads
targets, but that's not proposed just yet at this time.