I have two Windows-wheel-related questions:
- Are there any hints / guides / steps / examples for building a compiled wheel on GitHub actions that is compatible with a given Windows version? I’m specifically struggling with supporting Windows older than 8.1 since that’s what my toolchain happens to target, but I don’t understand how the base target version is specified at all.
- Is there a
manylinux-style mechanism for indicating that a wheel requires a base Windows version, and if not, is this on purpose or just “we haven’t gotten there yet”? I have a feature request for AF_UNIX support which I understand is new in Windows 10, and I don’t know how to go about building appropriate wheels.
I just published my first release (v21) of pyzmq from GitHub actions using cibuildwheel after migrating away from my own manual setup on appveyor, and immediately faced some compatibility issues. My new build toolchain with VS2017 is targeting Windows 8.1 as the minimum supported version (import on Windows 7 fails with “ImportError: DLL load failed: The specified module could not be found.” due to missing symbols revealed by Dependency Tracker, e.g. API-MS_WIN_CORE_COM_L1-1-0.DLL).
I’m not a Windows build expert, but I cannot find a way to build wheels that work on Windows 7, a la MACOSX_DEPLOYMENT_TARGET. It seems Python’s own builds with apparently the same toolchain do work, so there might be someone here who knows. VS2017 doesn’t appear to be compatible with the 7.1 SDK, so I don’t understand what to do to make things compatible. Do I just need to bundle more of the vc_redist files?
If it is not feasibly fixable (or in general if I had a project with newer Windows required on purpose, such as for AF_UNIX support), how can I communicate that my latest wheel requires Windows 8.1 (or whatever version) and should not be considered for installation on earlier versions?