Skip bundling the MSVC C++ runtime when repairing cross-compiled win_arm64 wheels

[Copilot]

The build (windows-latest) job fails while repairing the ARM64 wheel:

+ delvewheel repair -w ...\cp39-win_arm64\repaired_wheel -v ...-cp39-cp39-win_arm64.whl
FileNotFoundError: Unable to find library: msvcp140.dll

Root cause: cibuildwheel 4.x runs delvewheel repair by default on Windows (3.x did not). windows-latest is x86-64, so the ARM64 entry in [tool.cibuildwheel.windows] archs is cross-compiled — delvewheel then looks for an ARM64 msvcp140.dll to vendor, and only the x64 copy is discoverable on the runner. x86/AMD64 repair fine.

Changes

• pyproject.toml: added a build-identifier override that repairs *-win_arm64 with the MSVC runtime excluded. The VC++ runtime is a redistributable system component, so leaving it unbundled matches what every wheel published under cibuildwheel 3.x already did.

[[tool.cibuildwheel.overrides]]
select = "*-win_arm64"
repair-wheel-command = "delvewheel repair --exclude msvcp140*.dll -w {dest_dir} -v {wheel}"

The glob covers the whole msvcp140* family (msvcp140_1.dll, msvcp140_atomic_wait.dll, …) so a future import doesn't reopen the same failure. concrt140.dll is only reachable as a delay-load dependency of msvcp140.dll, so it drops out with it. x86/AMD64 keep the default repair command and continue bundling their dependencies.

Alternatives considered: pointing delvewheel at the VS ARM64 redist tree via --add-path (requires hardcoding or globbing a versioned MSVC path in CI), moving ARM64 to a native windows-11-arm runner (splits the Windows matrix job), or disabling repair for all of Windows (loses bundling on x86/AMD64).

[Paul Linnerud (paullinnerud)]

Copilot, with this change will an ARM64 build still be produced?

[Copilot]

Copilot, with this change will an ARM64 build still be produced?

Yes. The override only changes how the wheel is repaired, not whether it's built — archs = ["x86", "AMD64", "ARM64"] is untouched, so cp3XX-win_arm64 wheels are still compiled and land in wheelhouse/ for the upload step.

The ARM64 compile+link was never the problem: in the failing run the wheel built fine (Successfully built vttcompilepy-0.0.1.13-cp39-cp39-win_arm64.whl ✓ 35.81s) and only the subsequent delvewheel repair blew up. In delvewheel, an excluded DLL is put in the ignored set before it tries to locate the file, so --exclude msvcp140*.dll skips the lookup that raised FileNotFoundError and the repair completes normally, writing the same ...-win_arm64.whl to {dest_dir}.

The one difference is that the ARM64 wheel won't have msvcp140.dll vendored inside it, so it relies on the VC++ redistributable being installed on the target machine. That's the same as every ARM64/x64 wheel published before cibuildwheel 4.x, which didn't repair Windows wheels at all. x86/AMD64 still use the default repair command and keep bundling.

The current run's build (windows-latest) job is ~30 min into "Build Wheels" and still going — well past the ~22 min mark where it previously died on cp39-win_arm64, so that build identifier is now getting through.