Support MinGW builds
Opened this issue · 3 comments
#13 outlines some of the reasons why MinGW builds might be advantageous, but there is also the benefit of gcc/clang toolchain being more managable, and the possibility of using cross-compiling.
The MinGW builds of Python are quite mature, and well maintained with a long list of patches at
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python3
There are around 350 Python packages being built and tested in that repo, some with extra patches required.
I have built around around 150 myself on top of wine at https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages & https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages-p2 , most with tests running. Builds there disabled to avoid unnecessary load on OBS, but I was able to build standalone CLI apps with it.
(Also Nuitka-built apps at https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages-Nuitka ;-) )
I'm all for supporting a MinGW distribution (as well as a Clang on Windows distribution).
I'll be honest, the nhe number of patches required to build CPython for MinGW scares me a bit. It might be less effort (and more useful) to cross-compile a Windows distributing using Linux+Clang.
Well the number of patches is the side effect of real users, which is something a new project to build with clang doesnt have. And you would still need many of those patches from MinGW project, which are often run-time patches. As I know you are aware, getting cpython built is only the beginning - to be useful, the distutils needs to be able to compile modules which link correctly, and that is when the patches start piling up.
Anyways, the more the merrier.
Cross linking to indygreg/PyOxidizer#95 which seems blocked on this, or a clang build.
This may be possible with the msys2-UCRT version, I have to do a lot less patches compiling with this and most of the time it just works without issues or even the clang toolchain: