cibuildwheel for windows

[ffgan]

see #211 (comment)

The CI results show that everything has passed. You can view the details at https://github.com/ffgan/openblas-libs/actions/runs/18747245828
I have merged the win and win on arm configurations into posix.yml and renamed that file to wheel.yml.
Regarding travis, since I cannot debug locally, I may add related commits in the PR to pass travis.

---

other info
Co-authored by: nijincheng@iscas.ac.cn;

---

• I updated the package version in pyproject.toml and made sure the first 3 numbers match git describe --tags --abbrev=8 in OpenBLAS at the OPENBLAS_COMMIT. If I did not update OPENBLAS_COMMIT, I incremented the wheel build number (i.e. 0.3.29.0.0 to 0.3.29.0.1)

[mattip]

Thanks! Rebased on top of #220

[ffgan]

Hi @mattip. Could you temporarily disable Github Action for this PR? I may need to frequently commit to this branch to debug travis. If CI isn't disabled, it would waste CI resources.

[mattip]

Sure, I disabled actions. Does the travis workflow work locally when run in a docker container with the appropriate --platform argument?

[ffgan]

Sure, I disabled actions. Does the travis workflow work locally when run in a docker container with the appropriate --platform argument?

It can run locally, but I tried it and encountered issues like illegal instruction errors. My local machine is fedora + x64. For s390x build, I running s390x containers with QEMU, illegal instruction problems are difficult to troubleshoot.

What's even more troublesome is the environment issue - it's relatively difficult to reproduce the travis CI environment locally. For example, travis uses Python 3.10 by default. I just tested on travis and found that cibuildwheel 3.x doesn't actually support Python 3.10 (Or simply put, I didn't carefully check the documentation. ). I need more information before I can provide cibuildwheel support for travis.

[ffgan]

Now travis is fine, but due to some unknown reasons, same as before, two jobs failed at the very beginning. This might require reaching out to Travis maintainers for more help.

We can now enable GitHub Actions for more testing.

If there are any issues, please feel free to @ me directly.

[mattip]

I re-enabled github CI and changed the macos-x86_64 build to run on macos-15-intel. Thanks for the progresss so far.

[mattip]

@ffgan what would you think about keeping the windows builds separate from the posix ones? Many of the build steps are conditional anyway. Once we rationalize the batch vs. bash differences in the two windows builds, we can think about uniting the workflows.

[mattip]

Is there a cibuildwheel option to get the logs to be open? It is frustrating to have to continually scroll to the end to get the next 30 lines in a thousand line log.

[mattip]

Switching to macos-15-intel made the build fail like in #216. I guess this is better than producing a faulty wheel, as in issue #219. It seems there is a problem with these builds. I wonder how upstream is building and testing macos-x86_64 since the macos-13 images are EOL.

[ffgan]

Is there a cibuildwheel option to get the logs to be open? It is frustrating to have to continually scroll to the end to get the next 30 lines in a thousand line log.

Perhaps this link will be useful to you, https://cibuildwheel.pypa.io/en/stable/options/#build-verbosity

[ffgan]

Switching to macos-15-intel made the build fail like in #216. I guess this is better than producing a faulty wheel, as in issue #219. It seems there is a problem with these builds. I wonder how upstream is building and testing macos-x86_64 since the macos-13 images are EOL.

I agree with your idea - compile-time errors are better than runtime errors. Let's try our best to figure out how to make the CI pass here.

[ffgan]

Switching to macos-15-intel made the build fail like in #216. I guess this is better than producing a faulty wheel, as in issue #219. It seems there is a problem with these builds. I wonder how upstream is building and testing macos-x86_64 since the macos-13 images are EOL.

I found some possible issues and related PRs. I'm now testing whether the patches mentioned in them can be applied.

OpenMathLib/OpenBLAS#5477

OpenMathLib/OpenBLAS#5478

[mattip]

Tou can change the OPENBLAS_COMMIT to develop which will pull in that PR and more

[mattip]

We should get #223 #225 to pass before merging this. Anyway we need to think about combining windows and posix yml files.

[mattip]

This needs a rework. We no longer have travis, so we could try to merge the windows x86_64 and arm64 builds to a single format, preferably based on bash, and then try to merge that to posix so we only have one build sequence.

[mattip]

See #228

[ffgan]

Hi @mattip .

Maybe things will be slightly trickier than expected. I think it would be better not to touch this bat file for now, because the operations involved in the bat file are somewhat troublesome. I'll try to reorganize this PR later, with the goal of making the build on Windows also use cibuildwheel.

After this PR is merged, we can then modify this bat file. This way, the PR review burden will be smaller.

[ffgan]

Some simple descriptions.

After thinking it over, I found that simply putting the Windows part into POSIX isn't really ideal. However, for now at least, everything is uniformly using cibuildwheel, so let's just leave it as is for the time being. In some existing places, the default bash must be switched to use pwsh. If it's not pwsh, there will be some strange issues - for example, make install will have problems. Or there's that very strange issue about which bash environment it actually is, or the space issue in the bash path Program Files. Or whether it should be \ or /. In short, debugging this on Windows can only be described as a nightmare. But for now, getting CI to pass is already the best result of my attempts.

Regarding the fact that most of the scripts in posix.yml are only used for Windows, I think there are two directions we can go. One is to move the bash scripts directly out and put them back in the regular script area, not bringing them into CI here. The second is to split up the CI, using a method similar to the use approach in CI to call/initialize the Windows environment, which would preserve CI support very well. Due to time constraints, I haven't tried this yet. Actually, there's an even more troublesome issue - the cache problem. If there's no cache, I strongly advise against attempting to refactor the Windows scripts - each attempt takes at least an hour, and even the most patient person will be worn down mentally.

[ffgan]

cc @mattip