On Sun, Aug 8, 2010 at 12:27 AM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> FYI, distutils is frozen because even minor bug fixes have broken third-party tools in the past, that’s why new features and bug fixes land in distutils2. Only some bug fixes that are sure not to break things make their way into distutils. distutils2 will be reintegrated into the stdlib in 3.2 or 3.3, but standalone releases will be made for Python 2.4 up to 2.7 and 3.x.

 eric,

 it's been a year since i did the mingw32 port so i'll try to recall
what it was that i did, but i have recollections of also having to add
to distutils, specifically adding an extra compiler class and an extra
linker class, derived from cygwin i believe (and then adding,
obviously, platform detection logic and options to make use of them).

 using logic analysis on the conditions, it can be shown that there is
nothing that can satisfy the conditions (one of which is "distutils is
frozen", another is "distutils will not go into python2.N or 3.x"
etc).  thus, something has to give.

 detailed analysis and recommendations follow:

 if distutils2 is to be "standalone" it literally makes it impossible
to build python 2.4 up to 2.7 and 3.x using mingw32, because the build
infrastructure will be entirely missing.  how can you build python 2.7
using mingw32 if one of the critical dependencies - actually saying
"use mingw32" - is missing?!!

 the decision to keep distutils frozen therefore forces the mingw32
developers to create a "special" version of distutils, one which has
to be added as a patch to python - let's call it distutils_mingw32 -
which has the exact same functionality as distutils except that it is
extended to have a mingw32 compiler and linker class.   adding such a
patch (which adds a copy of distutils called distutils_mingw32) would
be extremely disruptive, as it would defeat the entire purpose of
distutils, and i would be extremely surprised if it was accepted.

 so, unpalatable-as-defined-by-previous-negative-experience as it may
be, the only sensible option is to do an extremely careful and
thorough review of LRN's distutils compiler and linker class
additions, and ensure that they are _purely_ additional classes, even
at the expense of duplicated code.

 please remember that mingw32 is an _additional_ platform, not a
change to any _existing_ platforms.

l.

p.s. the only other option i can think of would be to add in
build-time options where you can specify the fully-qualified path to
where distutils2 can be found.  this would be somewhat... contrived,
but would "work".