ci: enable Win ARM

[henryiii]

Will un-draft when I download the produced wheel and test locally.

[wjakob]

What's the status on this PR? Are we waiting for a future cibuildwheel release?

[henryiii]

The problem is https://gitlab.kitware.com/cmake/cmake/-/issues/25001. Since nanobind sets the extension separately (like pybind11), and since scikit-build-core does make the correct extension available, we could fix it in nanobind but not generally; maybe that's the best way to go for now.

[wjakob]

Checking in on the status of this PR as the CMake blocker issue sounds like it's unlikely to be fixed.

[henryiii]

Yeah, there's two options. One would be to check and see if SKBUILD_SOABI is defined, then use that. That's always correct, and nanobind could just look for that and override if present. The other would be for scikit-build-core to cause Python to report the cross-compiled values so that FindPython picks it up, and that was hard and the PR is on hold. There continue to be good reasons to allow us to set the SOABI from scikit-build-core, so I'm still holding out hope that there might be an option someday.

But the best course of action for nanobind specifically is to check for SKBUILD_SOABI and use that if set.

[wjakob]

Like this? wjakob/nanobind#483. I am not quite following the subtleties as to where SKBUILD_SO[S]ABI and/or Python_SO[S]ABI is defined. My assumption would have been that they are equivalent when run via scikit-build-core.

[henryiii]

That looks correct. They are usually equivalent when running in scikit-build-core, but if they differ, scikit-build-core is pulling the value from the running Python using the standard mechanisms (including respecting cross-compiling) while FindPython is setting Python_SOABI from a subprocess call and it's getting it incorrectly when cross-compiling.

scikit-build/scikit-build-core#355 would fix FindPython by getting the Python subprocess it calls to report the cross-compiling values, but it's tricky to get right.

[wjakob]

closing in favor of #43.