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 -- http://mail.python.org/mailman/listinfo/python-list
