Build win_arm64 wheels#1733
Conversation
Add a native windows-11-arm runner to the release workflow's wheels matrix so win_arm64 wheels are built alongside win_amd64, with identical feature enablement (cibuildwheel 4.1.0, BUILD_EXTENSION=yes, and the enable=["pypy"] setting inherited from pyproject.toml). On the ARM64 runner cibuildwheel's default arch is ARM64, so no other configuration change is required. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 62020684-81fd-4cd7-8458-6333d0ad74f1
|
Is there a |
Do you have a link to the logs of that CI run? Just want to see for myself what it builds exactly :-) |
Here it is ;D |
Sadly, there seems to be no |
|
It has been requested and the maintainer "can’t give a definitive answer right now regarding adding and maintaining such aliases." |
|
Now trying to build on through cross-compilation in #1734 so I can stick to the previous set of just three build machines. There's an argument for distributing the build across more machines, but declaring which machine builds what gets messy. |
|
Cross-compilation works, see https://github.com/python-websockets/websockets/actions/runs/29437109248/job/87426425280. |
What
Add a native
windows-11-armrunner to thewheelsmatrix in the releaseworkflow so that win_arm64 wheels are published alongside the existing
win_amd64wheels.Validation
The
windows-11-armCI job succeeds and produces the same CPython set aswin_amd64:cp311,cp312,cp313,cp314, and free-threadedcp314t.Every
win_arm64wheel produced by that CI job was then downloaded from thepipeline and tested on a native Windows ARM64 machine with its matching
interpreter. For all five wheels the
speedupsC extension loads,apply_maskoutput is byte-identical to the pure-Python reference, and the Sans-I/O test
suite passes (915 tests: frames, protocol, HTTP/11, streams, extensions, URI,
legacy framing/handshake):