Add Windows MSYS2/MinGW wheel builds to python-wheels CI#827
Add Windows MSYS2/MinGW wheel builds to python-wheels CI#827GregoryMorse wants to merge 5 commits into
Conversation
- Add windows-latest to the build matrix in python-wheels.yml - Set up MSYS2 with MinGW toolchain (gcc, cmake, ninja, gmp, zlib, pkg-config, ccache) - Add MinGW to PATH and set CC/CXX for cibuildwheel - Configure CMAKE_GENERATOR=Ninja and PKG_CONFIG_PATH via CIBW_ENVIRONMENT_WINDOWS - Add [tool.cibuildwheel.windows] to pyproject.toml with delvewheel repair and Windows-compatible test-command Windows was already present in build.yml and release.yml but was never added to the Python wheel workflow. This uses the same MSYS2/MinGW approach.
cmake -E create_symlink requires Developer Mode or admin rights on Windows. Use cmake -E copy_if_different instead on WIN32, which works everywhere. This fixes the Python wheel build on Windows runners without Developer Mode and also helps local Windows builds outside the MSYS2 shell.
ccache from MSYS2 breaks when invoked outside the MSYS2 shell (CreateProcess fails). Override cmake args via SKBUILD_CMAKE_ARGS on Windows to exclude ccache launcher. Also set MSYS=winsymlinks:nativestrict so native symlinks work when Developer Mode is enabled on the runner.
|
I am able to build fine on Windows x64 with the latest MSYS2. Unfortunately I cannot test the release workflow (easily at least) but if enabled, and issues remain, I will solve them. The last PyPI Windows version still has crash issues so it would be really nice for a fresh release there. |
|
Ah nice, thanks! Is this PR AI-generated? Would be nice to disclose. If so, did you review it? Regarding: " The last PyPI Windows version still has crash issues so it would be really nice for a fresh release there." --- ooops. |
The msys2/setup-msys2@v2 action installs to a runner-specific location
(e.g. C:/mingw64 on GitHub Actions, C:/msys64 locally). Hardcoding the
path caused 'Could NOT find PkgConfig' because PKG_CONFIG_PATH and the
GITHUB_PATH addition pointed to a nonexistent directory.
Fix:
- Use cygpath -m /mingw64 inside an msys2 {0} shell to resolve the
actual Windows path at runtime
- Store MINGW_PREFIX and MINGW_BIN in GITHUB_ENV for subsequent steps
- Use mingw-w64-x86_64-pkgconf (replaces pkg-config package, which
conflicts and gets skipped)
|
@msoos Hi and thanks for the approval. Yes this is AI generated by DeepSeek v4 Pro operating under Copilot. The local build working fine is not surprising (on Python 3.14 in fact) as you did a recent PR with some work there. I did look through the changes but as its very GitHub environment specific - I am now going to fix the issues as they come and make some commits until it is fully working. |
CIBW_ENVIRONMENT_WINDOWS now includes PATH so delvewheel can locate libstdc++-6.dll, libgcc_s_seh-1.dll, and libwinpthread-1.dll during the repair step. Without this, the built wheel may lack these runtime DLLs, causing 'DLL load failed' at import time.
|
So I have done as much exhaustive local testing as I can do to try to ensure this will run on GitHub's Windows environment. Fixed any DLL issues, and silly hardcoded path issues. Ive run |
|
I'm also fixing now a long pre-existing point of pain on the Python variant, the Ctrl+C support to disrupt potentially very long runs. |
|
The Ctrl+C support across multiple pycryptosat runs is working flawlessly including relinquishing it back to Python when not needed. The Windows builds also working for standalone and Python, and the cibuildwheel routes. It might still have GitHub workflow issues but I don't know what I can do besides solve them one by one as you approve the workflow. Usually it can be solved in a few runs though, as everything is stable and tested. |
|
Hi, I don't like this python lib sigint handler. If you remove it, I'll approve another run for the Windows pypi package to let it build. But this complex signal handler is really unnecessary I think. Looks complex, and hard to debug. Even the normal handler I kinda hate it :) Probably should be removed. But anyway, the python one is definitely not a great idea. |
|
I converted this a draft. When you think you are ready, you can mark it "ready for review", I will then review and kick off the pypi build. Thanks! |
GregoryMorse
force-pushed
the
add-windows-python-wheels
branch
from
fe5803f to
691edb1
Compare
|
OK. Please clone the repo, make it work there, and then once it's working, please create a PR here :) Otherwise it'll take a week before this is done. Actions are notoriously hard to debug, and you'll need to do this many times. And I can't approve every time. So just clone, make it work in your own copy and then you don't need approval. Waaaay easier for both you and me :) Thanks! Closing in the meanwhile. |
2 participants
Windows was already present in build.yml and release.yml but was never added to the Python wheel workflow. This uses the same MSYS2/MinGW approach.