[issue10504] Trivial mingw compile fixes

[Martin v. Löwis]

Martin v. Löwis <martin at v.loewis.de> added the comment:

> Why exactly are you skeptical? Because it doesn't fix everything in
> one go? The other changes are also minimal (I'm not even sure if it
> requires more source changes, maybe I have just to get my #defines
> right). If you prefer to see a single patch which you can reproduce
> to fix MinGW compilation completely, I'm willing to do that.

Only bug fixes are acceptable for the 2.7 branch. If this *doesn't*
actually fix the bug (i.e. allows building Python with mingw), then
it's not a bug fix. Mere "improvements" are not acceptable for that
branch.

We have a long tradition of people proposing patches "we need this
and that code to support this and that platform". Then, right after
applying the patch, they come back with more patches, and after
that with more patches. I can accept this for the trunk if it doesn't
break anything, but not for a maintenance branch. The objective should
be to have the minimal necessary amount of changes that just address
the goal of the maintenance branch (i.e. fixes). Work in progress
doesn't belong here (some will argue that work in progress doesn't
even belong to the trunk, but should be carried out in a separate
branch).

> Given that 2.7 is supposed to be a long time support version, I
> really think people should have a chance to use MinGW. The patch is
> trivial, but figuring out everything from the compiler error messages
> can be brain bending.

If this bug (which, unfortunately, hasn't been identified clearly,
either) ever gets fixed, I'm open for backporting it (with the
release manager's approval - it could also be considered as a new
feature - port to mingw - in which case it also would be out of
scope).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________