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

[Paul Moore]

On 27 October 2014 12:30, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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).

Thanks Nick. That explanation makes sense to me. I was aware of this
sort of scenario, and as I've said before I don't have any objection
per se to making things easier for people with that sort of
requirement. But some of the other arguments in this thread seemed to
imply more than that. Without specifics, though, I concede that I may
be over-interpreting the rhetoric, so that's the part of the debate
I'm stepping back from, to avoid descending into FUD.

Paul