Windows arm64 support - #328
Open
knightmare2600 wants to merge 7 commits into
Open
Conversation
relenv/build/windows.py already carried arm64 plumbing (OpenSSL VC-WIN64-ARM target, arch_to_plat/arch_to_archname mappings) that was never reachable because arches[WIN32] had arm64 commented out since 2022, pending "Python 11" support that has long since landed. Uncomment it so relenv build/create/fetch accept --arch arm64 on Windows. Add build_windows_arm64 and test_windows_arm64 jobs targeting the windows-11-arm hosted runner (native host==target, unlike the existing x86 job which cross-builds on windows-2022), plus an explicit VS ARM64 VC++ tools install step since install_vc_build.ps1 only ever requests the x86/x64 workload. Untested pending an actual CI run. Tracks saltstack#280.
MSFT_VSInstance (root/cimv2/vs) isn't registered on the windows-11-arm runner image even though VS 2022 Enterprise ships pre-installed there. The CI run against build_windows_arm64 confirmed this in practice: the script reported VS as "Missing" and spent 50+ minutes downloading and laying out a VS 2017 build-tools bundle instead of using the VS 2022 already on the box. Fall back to vswhere.exe -- present on every GitHub-hosted Windows image regardless of CIM provider support -- before concluding VS needs a from-scratch install.
setup-python has no arm64 Windows build for 3.10 ("The version '3.10'
with architecture 'arm64' was not found for Windows Enterprise") --
CPython's official arm64 Windows installers only started at 3.11. All
5 build_windows_arm64 jobs succeeded in the prior run (confirming the
native ARM64 CPython+OpenSSL build itself works); this only fixes the
verify job's own bootstrap interpreter, matching what
build_windows_arm64 already uses.
test_pip_install_cryptography and test_pip_install_idem failed on the windows arm64 build: pip fell back to compiling cryptography from source (no win_arm64 wheel exists yet -- nothing has ever shipped one for this target before), and openssl-sys couldn't find an OpenSSL to link against (OPENSSL_DIR unset, no vcpkg). relenv already builds OpenSSL from source for arm64 (update_openssl's VC-WIN64-ARM path); copy that install tree into the onedir as OpenSSL/ and archive it, then point OPENSSL_DIR at it in the two affected tests. No-op on every platform where OpenSSL comes from prebuilt binaries (prefix is never populated there) or where a wheel already exists.
Was added purely to dispatch CI runs manually while testing this branch without needing a PR. Not part of adding windows arm64 support; drop it to keep the change focused.
Closed
twangboy
approved these changes
Aug 26, 2026
Windows arm64 is a new build target (PR saltstack#328). Four verify tests break because they pin package versions that either don't have arm64 wheels on PyPI or don't compile from source under the MSVC arm64 toolchain: - test_pip_install_salt_pip_dir: Salt's transitive C-extension deps (pymssql, cryptography, cffi at the pinned old versions) have no arm64 wheels and their source builds need FreeTDS/OpenSSL/libgit2 for arm64 which is not available here. Xfail on win-arm64 matching the existing amd64 xfail. - test_install_with_target_cffi_versions: cffi 1.14.6 / 1.16.0 lack arm64 wheels (upstream arm64 support landed in cffi 1.17). Skip those two extra installs on win-arm64; the cffi_version path (1.17.1 / 2.0.0) still runs and covers the arm64-supported release. - test_install_with_target_{no_,}ignore_installed: cffi <1.17 and pygit2 <1.16 have no arm64 wheels. Pin to arm64-supported floors on win-arm64 (cffi 1.17.1/2.0.0, pygit2 1.16.0/1.19.2 by Python version) so the already satisfied: cffi and --ignore-installed flows still get exercised.
Contributor
|
@knightmare2600 I pushed some test fixes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Windows arm64 support
Resubmission of #318, which was accidentally auto-closed when my fork was deleted and has since been recloned. Same branch, same commits — nothing has changed content-wise, this is purely to restore the PR after the fork mishap.
Please See #318 for the original discussion and review context. CC:@dwoz