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

Paul Moore p.f.moore at gmail.com
Sun Oct 26 23:41:39 CET 2014

On 26 October 2014 13:12, Tony Kelman <kelman at berkeley.edu> wrote:
> Only cross-compilation and the build system in the above list are relevant
> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are
> real reasons for some groups of users and developers to prefer MinGW-w64
> over MSVC.

Not really, to be honest. I still don't understand why anyone not
directly involved in CPython development would need to build their own
Python executable on Windows. Can you explain a single specific
situation where installing and using the python.org executable is not
possible (on the assumption that the mingw build is functionally
identical and ABI compatible with the CPython build, the claim being
made here)? Note that "not possible" is different from "I don't want
to" or "it doesn't fit my views about free software" or similar. Also
note that building extensions is different - you have to assume that
building extensions using mingw with a mingw-built CPython is just as
hard as building them with a MSVC-built CPython (otherwise you've made
changes to extension building and you should contribute them
independently so that everyone can benefit, not just those who build
their own Python with mingw!)

> Paul Moore:
>> 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.
> I want to do exactly this in an automated repeatable way, preferably on
> a build service. This seems harder to do when CPython cannot itself be
> built and handled as a dependency by that same automated, repeatable
> build service.

I cannot see why you would need to build Python in order to build
extensions. After all, if your build service is on Linux, it couldn't
run a mingw-built Python anyway. If your build service is a Windows
machine, just install the python.org binaries (which is a simple
download and install, that can be fully automated, but which is a
one-off process anyway).

> Unless it becomes possible to cross-compile extensions
> using the build machine's own version of Python, which might be the right
> approach.

This may be where we are getting confused. I see this as the only
practical way of cross-compiling Windows extensions on Linux, by using
the Linux Python. So being able to cross-compile Python is not

On a tangential note, any work on supporting mingw builds and
cross-compilation should probably be done using setuptools, so that it
is external to the CPython code. That way (a) it isn't constrained by
the CPython release schedules and backward compatibility constraints,
and (b) it can be used in older versions of Python (which is pretty
much essential if it's to be useful, TBH).


More information about the Python-Dev mailing list