On 25 October 2014 21:50, Steve Dower <steve.do...@microsoft.com> wrote: > Ray Donnelly wrote: >> What is it that you >> are afraid of if CPython can be compiled out of the box using >> mingw/MinGW-w64? Why are you fighting so hard against having option. > > I'm afraid of users having numpy crash because they're using an MSVC > CPython instead of a mingw CPython. I'm afraid of users not being able > to use library A and library B at the same time because A requires MSVC > CPython and B requires mingw CPython. (I can produce more examples > if you like, but the general concern is having a fragmented community, > as I said in my previous post.)
Precisely. Either developers test with *all* supported compilers, or there is a risk of incompatibilities. Advocates of supporting mingw as a build system for Python generally do *not* suggest that they are willing to test for, and deal with, cross-version compatibility issues. Typically mingw is seen as "another platform" in some sense, by such advocates, having its own set of supporters and maintainers. The possibility of extensions built with a mingw-compiled Python failing when used under a MSVC-built Python is real. It's difficult to say how big that risk is, but it's certainly there. And I see no-one offering to be responsible for such compatibility issues (the mingw supporters generally don't want to set up a MSVC build chain, so it's difficult to see how they could credibly offer). > I'm fighting against "having options" because it will suck up the precious > volunteer time we have and direct it away from where it would be more > useful, which is making it easier to build extensions with other compilers. And claiming that it doesn't suck up developer time ignores the point I made above - *someone* has to deal with any compatibility issues that come up. As a starter, does the wheel format need to include tags to distinguish whether the target Python is MSVC-built and mingw-built? Who will check that? If there is a need, who will work on the code needed to incorporate that change into wheel, pip, and the relevant PEPs? As Steve says, the Python community has a genuine, strong need for people with mingw expertise working on making it easier to build *extensions* using mingw, that work with a MSVC-built CPython. If it were possible to cross-compile compatible extensions on Linux, projects developed on Linux could supply Windows binaries much more easily, which would be a huge benefit to the whole Windows Python community. But the mingw experts don't want to work on that, preferring to develop patches allowing CPython to be built with mingw. No objection from me, it's your free time, use it as you wish, but as a Windows user of Python I can confirm that it's not what I'd like you to be doing as your contribution to Python. > I would love to see extensions for Windows built on all platforms. I see no > value in building Python itself for Windows from different platforms. Exactly. > If other core developers agree with you that a more "pure" build of Python is > worthwhile, then they can go ahead and merge the patches (though I suspect > most would like to see some traction achieved on a fork first). I think it's > important that I (as Windows build manager) make my own position clear, > that's all. Personally, I'm not a core developer, just a long-time member of this list and occasional contributor to discussions. But I am also a core pip developer and a Windows user, and from that perspective I am acutely aware of the common pain points for Python users on Windows. And they are all about binary extensions, and none at all about building Python itself. So in my view, being able to build CPython using mingw is somewhat interesting from a theoretical perspective, but of little or no practical value[1] and disruptive in a number of ways, as mentioned above, to improving the overall experience of Python users on Windows. Paul [1] I note, without trying to make a judgement, that many of the benefits cited for building with mingw are around "being able to use free tools" or similar essentially ideological issues. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
