This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients BreamoreBoy, WhiteTiger, arbitraryvalue, cdavid, cgohlke, cournape, donmez, eric.araujo, giampaolo.rodola, jdpipe, loewis, paul.moore, r.david.murray, ralf.gommers, rpetrov, rubenvb, scott.tsai, simonzack
Date 2015-05-19.08:17:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432023461.41.0.556590450473.issue4709@psf.upfronthosting.co.za>
In-reply-to
Content
Ruben,
Thanks for the detailed explanations. Just to be clear, I am *not* the person that will take this aspect of the process forward - that will be the community of people building (or wanting to build) extensions for Python with mingw. I don't know if that community has a spokesperson yet (or even if it's a well-defined "community") but they would be the ones to to engage with the mingw developers.

In particular, the choices around ABI incompatible variants that you mention are precisely the sort of thing the community needs to establish - which variant is compatible with Python, how to get a maintained build of that variant (there seems to be a lot of "get such-and-such's personal build from this URL" in the current crop of instructions for building Python extensions with mingw - that's not really sustainable).

The problem boils down to there needing to be a definitive, simple, and maintained set of instructions and software for "how to set up a mingw build environment for Python extensions". The core Python developers can't provide that (as we use MSVC). What we can do, when such a thing exists, is look at whether it's a toolchain that we can reasonably support.

At the moment mingw patch requests come in based on someone's custom build environment, that we can't easily reproduce, and we can't be sure is the same as anyone else's. That's not something we can support - hence the frustration from the mingw-using community, because we have partial support from the days when mingw.org and cygwin were the only two options for gcc-on-windows and we didn't really communicate the change in status (which admittedly would have been "we no longer support mingw", so wouldn't have helped much...)

Hopefully, the discussion on this issue clarifies the position a bit. Give us a well-defined "gcc on Windows" (mingw) platform definition, and we'll look at supporting it. Otherwise, we can maintain the status quo (what's there remains, but patches pretty much never go in, because reproducing issues and testing changes is too much effort to be viable) or formally drop support for mingw (which I'd be reluctant to do, but it may be worth it just to offer clarity).
History
Date User Action Args
2015-05-19 08:17:41paul.mooresetrecipients: + paul.moore, loewis, jdpipe, giampaolo.rodola, donmez, scott.tsai, cdavid, eric.araujo, rpetrov, r.david.murray, cgohlke, rubenvb, WhiteTiger, BreamoreBoy, cournape, arbitraryvalue, ralf.gommers, simonzack
2015-05-19 08:17:41paul.mooresetmessageid: <1432023461.41.0.556590450473.issue4709@psf.upfronthosting.co.za>
2015-05-19 08:17:41paul.moorelinkissue4709 messages
2015-05-19 08:17:40paul.moorecreate