> It is certainly desirable to be able to build extension modules
> with this configuration;

 yeah, and the nice thing is - it works, too! :)

> AFAIU, distutils already supports that case.

 not without modification, it doesn't: #3871 adds "proper"
 mingw32 compiler detection and link options, such as support
 for dll.a which isn't auto-detected (but is on cygwin)

 etc. etc.

> Whether or not it is desirable to be build Python from
> source in this configuration, I don't know - most people that
> want to build with mingw seem to be using the Python binaries
> available from python.org, or from ActiveState.

 i tried that a few months ago.

 1) there is no .tgz for python-win32 so i was forced to
   install from a binary package

 2) there is no .exe so i was forced to install from msi,
   a proprietary installer - which as a free software
   developer, i have issues with, but i tried it anyway.

 3) msi installed, thanks to winetricks, but segfaulted
    and borked.  as i didn't really want to use it, i
    wasn't that unhappy.

 4) the msi turns out to be understood by the free software
    cabextract package.  but... the filenames are all borked
    and mangled.

 at that point, i decided i'd had enough: i wasn't going to
 go through 100 files looking for the one that _might_ be
 the python25.lib implib, plus other files that i'd need
 to do a non-proprietary-dependent build of python software.

> I'm not sure
> whether mingw is capable of building Python correctly, with
> assembly manifests and all.

 python setup.py build seems quite happy: rpetrov added .S
 to the compile-extensions and happily compiled win32.S
 in libffi with it.

 the only slight issue there is that the assembly file
 is incompatible with MSVC and so it borked (not at build
 time, unfortunately - at runtime).

 there's been a gcc bugreport raised, to get interoperability
 back (urk).

 GCC issue #36834.