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

Nick Coghlan ncoghlan at gmail.com
Mon Oct 27 13:30:31 CET 2014


On 27 October 2014 09:37, Paul Moore <p.f.moore at gmail.com> wrote:
> On 26 October 2014 23:24, Tony Kelman <kelman at berkeley.edu> wrote:
>> I want, and in many places *need*, an all-MinGW stack.
>
> OK, I'm willing to accept that statement. But I don't understand it,
> and I don't think you've explained why you *need* your CPython
> interpreter to be compiled with mingw (as opposed to a number of other
> things you might need around building extensions).

I can take a go at an explanation that may make more sense to you.
Consider one of our key requirements for packaging applications for
Fedora: that Fedora builds be *self-hosting*. Given a base Fedora
system, and a source RPM, we need to be able to *build the binary RPM
from source*. (Other Linux distros generally have a similar
requirement)

Relying on opaque binary blobs downloaded from the internet as part of
the build process is not permitted (modulo a few exceptions for
firmware blobs in device drivers).

Now consider that this "automatically rebuild the entire system from
source" model is not unique to Linux - you can use it for any system
where your build process is sufficiently automated, and you have a
need for it. However, the *structure* of those kind of automation
tends to differ wildly between POSIX style tooling (gcc, clang) and
MSVC. If you have an existing build automation system for *nix
targets, then cross-compilation via MinGW is likely going to be your
smoothest path to adding Windows binary support.

At that point, if CPython is one of your dependencies, you're going to
have the choice of allowing the python.org binaries to be pulled in as
opaque pre-built blobs, or else figuring out how to build an ABI
compatible version with MinGW rather than with MSVC. Think of this
more in the case of *embedding* the CPython runtime in a larger
context (e.g. in Tony's case, to make Python software usable with the
Julia runtime), rather than in building a standalone Python
interpreter for general use.

So, for embedding cases, and for incorporation into POSIX-style build
systems using MinGW-w64 for cross-compilation of Windows binaries, it
may make sense to incorporate the patches that allow building with
MinGW-w64 into mainline CPython (if I recall correctly, we supported
building with Intel's C compiler for a long time, even though we never
shipped anything built with it).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list