Build a Windows ARM64 wheel

[revarbat]

BelfrySCAD cannot run on Windows on ARM at all today: there is no openscad_cpp_evaluator wheel for it, so nothing else about that platform matters. PySide6 already ships win_arm64, so this was the missing piece.

openscad_cpp_evaluator-0.29.3-cp312-abi3-win_amd64.whl
openscad_cpp_evaluator-0.29.3-cp312-abi3-win_arm64.whl   <- new

Both verified built by an actual workflow_dispatch run of wheels.yml on this branch, not just reasoned about.

Cross-compiled, not built on an ARM runner

bison and flex are host build tools here — they generate C++ that MSVC then cross-compiles for ARM64. MSYS2, which is where this build gets a bison new enough for the grammar (3.8+; winflexbison3 ships 3.7.4, already proven too old by a past CI failure), has no native ARM64 build, so a windows-11-arm runner would have to emulate it. Cross-compiling on windows-latest sidesteps that entirely.

The one real obstacle

The compile succeeded first time; the failure was in the repair step:

delvewheel repair ... openscad_cpp_evaluator-0.29.2-cp312-abi3-win_arm64.whl
FileNotFoundError: Unable to find library: msvcp140.dll

delvewheel vendors the MSVC runtime into the wheel, and on an x86_64 host it can only find the x86_64 copy. The ARM64 wheel now excludes the runtime DLLs and leaves them to the system — which is what every Python extension on Windows already assumes, since CPython itself requires the redistributable. AMD64 keeps vendoring them, so its wheel is unchanged.

Known limitation

cibuildwheel skips CIBW_TEST_COMMAND for a cross-compiled wheel, because an x86_64 host cannot run an ARM64 one. So the ARM64 wheel is built but not smoke-tested in CI. Testing it needs a windows-11-arm runner, or hardware.

Version 0.29.2 → 0.29.3.

🤖 Generated with Claude Code