- E02 - Support for MinGW Open Source Compiler

[Pat]

Wow!  I must say, I'm less than impressed with the responses so far.  I
know Ilias can give the impression that he is just trolling, but I can
assure you he is not.  At least, not in this case.  ;-)

So in an effort to make some headway, I'm going to try to summarize the
current state of affairs.  The bottom line is that compiling C
extension modules on the Windows platform for Python 2.4 is, today, a
royal pain in the ass.  Period.  Here's why.

The main challenge is that extensions must be compiled using the same
runtime dll as that used by the Python interpreter itself.  The
official Windows binary installation of Python 2.3.5 and its
predecessors was compiled with one MS product, which was fairly easy to
support with minGW, but Python 2.4 was compiled with the newer .NET
compiler.  Unfortunately, compiling extensions for Python 2.4 with the
free MS tools is not trivial, as evidenced by Mike Fletcher's very
thorough document on the subject:

Python 2.4 Extensions w/ the MS Toolkit Compiler

http://www.vrplumber.com/programming/mstoolkit/

In addition, there are some unresolved licensing questions concerning
the .NET runtime file for extensions (msvcr71.dll):

http://mail.python.org/pipermail/python-dev/2005-February/051393.html

There have been extensive discussions about these issues on the
Python-Dev mailing list over the past couple of months (mostly in
December, but continuing to the present - see
http://mail.python.org/pipermail/python-dev/2004-December/thread.html
as a starting point), which seem to have fizzled out or at least
haven't resolved much.  The discussions made reference to work that has
already been done to allow Python to be compiled with minGW:

pyMinGW is a patch to Python source that aims to get Python to compile
under MinGW

http://jove.prohosting.com/iwave/ipython/pyMinGW.html

I've not seen any commentary on the quality of this patch, so that
doesn't appear to be the reason it hasn't been officially adopted.
Reading all the threads from Python-Dev has not enlightened me at all
as to what the underlying reason is for not adopting these changes.
Maybe there are good reasons, I just couldn't find them, and I'm
usually pretty good with Google.

A few of you have mentioned that minGW is not an optimizing compiler on
the Windows platform, whereas the MS .NET one is.  If anyone has
information on the performance differences, I'd really appreciate being
able to see it, particularly as it applies to Python 2.4.

Now, we get to the essence of my particular situation.  I've got a
project that includes some Python extensions written in C.  My users
(who are Python developers, but not necessarily hard-core types) need
to be able to work out of their local Subversion checkouts.  This
includes locally compiling these extensions as necessary.  I'd like
this to work with Python 2.4, and be as painless as possible on my
users.  I can't expect them to purchase a .NET compiler or go through a
bunch of configuration changes.  So far, I haven't figured out a good
way to support this.  I'm open to suggestions.  I suspect that my needs
are very similar to those of the original poster.

Perhaps the issue is in part a matter of minGW catching up with the new
MS compilers.  My understanding of and experience with Python 2.3.5 and
its predecessors has been that Python itself didn't need to be
recompiled with minGW, since extensions compiled with minGW linked to
the same C runtime dll.  So if minGW had support for msvcr71.dll then
maybe this problem goes away with Python 2.4 as well.

If anyone can shed any light on this situation, it would really help me
out.  Thanks.

--
Patrick K. O'Brien
Orbtech    http://www.orbtech.com
Schevo     http://www.schevo.org
Pypersyst  http://www.pypersyst.org