Refactor CI to produce 64-bit integer interface wheels for WoA

[Harishmcw]

This PR refactors the CI workflow to use a matrix strategy for building both 32-bit and 64-bit integer interface wheels for Windows-on-ARM (WoA).

• Simplifies the workflow and avoids code duplication.

• Ensures both 32-bit and 64-bit integer interface wheels are produced for WoA.

• I updated the version in pyproject.toml and made sure it matches git describe --tags --abbrev=8 in OpenBLAS at the OPENBLAS_COMMIT

[Harishmcw]

Hi @mattip and @matthew-brett ,

This updated WoA CI script now also generates the 64-bit integer interface wheel, which we can use to build NumPy for Windows-on-ARM.

[matthew-brett]

Is anyone using 32-but builds of Python for Windows on ARM?

If so, I guess we do need the INTERFACE64=0; BUILD_BITS=32 option. But I guess we also need an INTERFACE64=0; BUILD_BITS=64 option, for people building Numpy or Scipy with 32-bit interfaces, but 64-bit builds.

[rgommers]

No, 32-bit Python for Windows on ARM is not a thing, there's only win_arm64.

We do need LP64 (scipy-openblas32 ) and ILP64 (scipy-openblas64) wheels though, that's orthogonal to interpreter bitness.

[matthew-brett]

If so, I guess we do need the INTERFACE64=0; BUILD_BITS=32 option. But I guess we also need an INTERFACE64=0; BUILD_BITS=64 option, for people building Numpy or Scipy with 32-bit interfaces, but 64-bit builds.

Maybe I was incorrect here - but my comment was meant to say that we do not want or need a INTERFACE64=0; BUILD_BITS=32 build - as we have here, but we do want and need an INTERFACE64=0; BUILD_BITS=64 option, that I think we do not have.

[mattip]

Maybe the matrix/environment variables needs improvement. Both wheels can be imported by 64-bit python win-arm64.

The "32-bit" build uses INTERFACE64: 0, BUILD_BITS: 32. It prints Building for 64-bit binary, 32-bit interface at the beginning of thebuild step, and later prints out Compiling a 64-bit binary

[Harishmcw]

Hi @matthew-brett,

Just to clarify:

• In our workflow, BUILD_BITS does not refer to the binary architecture — it always builds 64-bit binaries for WoA. Instead, BUILD_BITS maps to the integer interface width used by OpenBLAS:

• INTERFACE64=0 → 32-bit integer interface → BUILD_BITS=32 → scipy_openblas32

• INTERFACE64=1 → 64-bit integer interface → BUILD_BITS=64 → scipy_openblas64

So we already have both:

• INTERFACE64=0; BUILD_BITS=32 (LP64)
• INTERFACE64=1; BUILD_BITS=64 (ILP64)

We use the BUILD_BITS variable purely as a naming and testing label — as seen here in the CI script:
windows-arm.yml#L76-L80

[matthew-brett]

Shouldn't we then remove BUILD_BITS on the basis that it's confusing, and have some variable like INTERFACE_BITS set internally to 32 for INTERFACE64=0 etc?

[mattip]

Thanks @Harishmcw. Once the wheels are uploaded to PyPI we can consider using scipy-openblas64 in NumPy.

[mattip]

I uploaded the 64-bit wheel. The next step is a PR to numpy/numpy to redo the win-arm64 wheel build to use it (simplifying the logic in tools/wheels/cibw_before_build.sh closer to what it was before numpy/numpy#29039) and releasing the condition on requirements/ci_requirements.txt.