You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add end-to-end support for building, testing, and releasing workerd on
Windows ARM64 (aarch64-pc-windows-msvc). This enables `npm install workerd`
to work natively on Windows ARM64 devices (e.g. Snapdragon laptops) via
the new @cloudflare/workerd-windows-arm64 package.
Bazel build system:
- Define arm64_windows-clang-cl platform in BUILD.bazel
- Add build:windows_arm64 config overriding the toolchain and execution
platform from x64 to ARM64
- Add build:release_windows_arm64 composing release_windows + windows_arm64
- Add build:ci-windows-arm64 for CI release builds
Rust toolchain:
- Register aarch64-pc-windows-msvc in RUST_TARGET_TRIPLES so rules_rust
downloads and configures a Rust toolchain for the new target
- Add the triple to supported_platform_triples in crates_vendor so the
Cargo dependency graph resolves for Windows ARM64
- Add win_arm64 config_setting_group and wire cargo-bazel to use the x64
binary under WoW64 emulation (no native ARM64 build available)
Host tools:
- Add @bazel_tools//src/conditions:windows_arm64 entries to wasm-tools
and clang-tidy selects, falling back to x64 binaries under emulation
NPM distribution:
- Create npm/workerd-windows-arm64/ package (os: win32, cpu: arm64)
- Add "win32 arm64 LE" to knownPackages in node-platform.ts
- Add @cloudflare/workerd-windows-arm64 to optionalDependencies in the
workerd meta-package and build-shim-package.mjs
CI/CD:
- Add windows-arm64 build matrix entry in release.yml using the
windows-11-arm GitHub Actions runner
- Add windows-arm64 upload-artifacts entry for release asset publishing
and npm per-arch package publishing
- Add windows-arm64 to test.yml matrix (debug builds excluded, matching
the x64 Windows exclusion for disk space reasons)
Note: the @local_config_cc toolchain name for ARM64 Windows is
auto-generated by Bazel based on what it discovers on the host. If the
first CI run fails with a toolchain resolution error, query
@local_config_cc//:all on the runner to find the correct label.
Made-with: Cursor
Copy file name to clipboardExpand all lines: RELEASE.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,4 +8,4 @@ The primary distribution channel for `workerd` right now is through `npm`. We us
8
8
9
9
## Cutting Releases
10
10
11
-
This is pretty simple, and completely automatic—every time the date in [release-version.txt](src/workerd/io/release-version.txt) changes, a new release is generated, along with the built binaries for `linux-64`, `linux-arm64`, `darwin-64`, `darwin-arm64`and `windows-64`. The types will also be generated and published automatically. This is governed by the [release.yml](.github/workflows/release.yml) GitHub Action.
11
+
This is pretty simple, and completely automatic—every time the date in [release-version.txt](src/workerd/io/release-version.txt) changes, a new release is generated, along with the built binaries for `linux-64`, `linux-arm64`, `darwin-64`, `darwin-arm64`, `windows-64`and `windows-arm64`. The types will also be generated and published automatically. This is governed by the [release.yml](.github/workflows/release.yml) GitHub Action.
0 commit comments