[Python-Dev] Status of C compilers for Python on Windows

Paul Moore p.f.moore at gmail.com
Sun Oct 26 00:36:59 CEST 2014


On 25 October 2014 21:50, Steve Dower <Steve.Dower at 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.


More information about the Python-Dev mailing list