Paul Moore added the comment: Supporting mingw building of extensions has always been a complicated process, mainly because there appear to be many variants of mingw (and in particular, there seem to be multiple 64-bit builds). Add to this the fact that cygwin is sometimes used as a cross-compiler (often using the same code in distutils) and it's hard to know what to support, or what will break.
I would be very happy to see support for building of Python extensions using mingw (even though I use MSVC myself). However, in order for core Python to have a stable target to aim at, I believe the users of mingw need to work to provide an easy to use, unified platform that can be the target for core support. I think the following would go a long way to giving the core developers (specifically me, I'd be willing to work on the core end of things to improve the situation) a chance of providing maintained support for using mingw as an alternative compiler for building Python extensions on Windows: 1. A well-documented and maintained process for setting up 32-bit and 64-bit mingw environments which can be used to build Python extensions. These need to use stable, well-maintained builds of mingw - ones that can be relied on to remain available in the long term (the links to equation.com and the Scipy instructions in this issue are now dead, for example, and both TDM and Mingw-W64 have been mentioned as toolchains, but it's not practical to try to support both - by support I mean at least that "some core developer installs them both and checks that things work"). Documentation patches to explain how to set up the official mingw build environment (once the community has agreed what it is) can be submitted to the packaging.python.org tracker. 2. Python 3.5 will be built using the MSVC 2015 "Universal CRT". From what I've seen on the mingw lists, there seem to be no plans for mingw to support this CRT in any form. Without that support, it's not clear to me how mingw builds for Python 3.5 will be possible, so the mingw community needs to work out how they will provide a solution for Python 3.5. Timely solutions for issues like this are needed if mingw is to be a supported build environment going forward. While it's understandable that the mingw community hasn't had much encouragement to work on things like this in the past, it is something that needs to change if full core Python support is to happen. So that's the position, really. If the mingw community can come up with an "official" mingw distribution that supports building extensions for Python 32 and 64 bit, including for 3.5+, I will look at how we ensure that distutils supports that distribution going forward (that will likely mean *dropping* support for other mingw builds at some point). I know the Scientific Python users make a lot of use of mingw for builds, so maybe their standard build environment is a good target to aim for. Bluntly, I'm not sure the community can achieve the above. It's a pretty hard goal, and lots of people have been working on it for a long time. But that's precisely why the core developers can't offer much in the way of support for mingw - it's too much of an unstable target as things stand. (Note for example, that I currently have *three* mingw 64-bit installations on my PC, and they all work slightly differently - to the extent that I have projects that I can *only* build with particular ones). With regard to this specific patch, it seems that according to msg132798 it's easy enough to work around the issue by manually defining the symbol. The patch seems to apply cleanly, still, but I'm not aware if it has been tested on cygwin, for example. So, like Martin, I'm reluctant to apply it just because it *looks* harmless. Particularly this close to the 3.5 beta deadline. ---------- nosy: +paul.moore _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4709> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
