• May 25th, 2006. Cleaned and updated pyMinGW. It now supports the SVN Python 2.4 branch, and trunk (currently 2.5aX). As the latter now includes ctypes, emphasis was put on trying to get the latter to build under MinGW. Almost all ctypes' tests now pass, except the callbacks which are still crashing the interpreter. (See the known issues document).
  
  Tix now compiles under MinGW, and is included as part of all versions of pyMinGW's binary extension packages.
  
  There is also experimental support for producing Python binaries and Python extensions that are compatible with the standard distribution (please read disclaimer in pyMinGW's license).
  
  
• Sept 28th, 2005. Updated pyMinGW to support Python 2.4.2 final. Please refer to the changes documents in the Download section below. Also released extension binaries.
  
  
• Aug 19th, 2005. Made a binary distribution of pyMinGW-Python 2.4.1 Build 0.0.6.5 for those who cannot build the extensions. This is just a binary packaging of the March pyMinGW-241 release. See the Download section below.
  
  
• Apr 13th, 2005. Access to the download files should now be okay. Working on updating the FAQ.
  
  
• Old news. Click here for access to pyMinGW's old news.
  
  

How To Apply The Patch

In source form. pyMinGW patches several Python source files, C code and Python code. These, and the same is true for pyMinGW's binary distributions, are all zipped up in a zip file which, when extracted to the root of Python, will overwrite some of the original Python files in their respective directories. So a word of advice: keep backups.

Figure 1. below shows how the directory tree should look like in Python 2.3.5 final from CVS with all the extensions mentioned in \PCBuild\readme.txt living side by side with the Python source.

Figure 1.

Figure 2.

Figure 2. above shows where the \MinGW directory (which is the heart of the pyMinGW distribution) goes. This placing will be automatically done by the unzipping procedure. You only need to specify that you want to unzip the pyMinGW package to the \src subdirectory of the Python source you are patching. The unzipping program will then create the \MinGW directory in the \src directory and will also patch all of the needed files to get Python to compile under MinGW.

Python source archieve vs. source from CVS/SVN. Please note that if you downloaded the Python source archieve (as opposed to the source from CVS/SVN) that your extracted Python source might not have a \src directory. If that is the case make sure that you extract the pyMinGW package where the \PCBuild, \PC, and \Include directories reside.

For more details, read the instructions in the readme file included in the pyMinGW source package (location: \MinGW\Readme.txt) on how to apply the patch, and how to build Python with MinGW.

Using binary distributions . If you are using the binary distributions then simply extract the packaged file to the root of your local Python directory, that is to where the \PCBuild, \PC, \Lib, and \Include directories reside.

This will create the \MinGW directory which will contain the Python binaries and at the same time patch several Python source files, all distutils related. To use your MinGW compiled Python, change directory to where the new MinGW directory is and type python at the prompt.

Upgrading from an earlier version. If you are upgrading from an earlier version of pyMinGW then you should not have a problem if you used the same directory tree structure as shown above. You can always of course delete the old MinGW directory and start fresh. Or you can simply extract the new pyMinGW version to the root of Python source- like you did before- and everything should be okay.

If you used earlier versions of pyMinGW which used a different directory structure than the one mentioned above, then apply pyMinGW first and then simply cut and paste the subprojects' directories until your local Python source tree looks like the one shown above. If, on the other hand, you were brave enough to play with other Python source files not modified by the patch, then (just to be safe) you should get a fresh copy of Python source to apply pyMinGW to. You should always keep that fresh copy handy in case you need a clean start to the Python build procedure.