Aside from maintaining Simply Fortran, I spend a good deal of my time working in Python. As one might guess, I also spend most of my time working on various versions of Windows these days. Many (many, many…) people online complain about the difficulties in working with Python on the Windows platform. Generally speaking, though, I encounter few issues on the Windows platform with the exception of C extensions.
Python modules that incorporate C extensions (or Fortran or C++) require a compiler to be present obviously. On GNU/Linux systems, there usually isn’t an issue as most distributions either already have or make it trivially simple to install the GNU Compiler Collection. On Windows, however, the issue is a bit more complicated.
Python’s distutils module does provide support for a handful of compilers: Microsoft Visual C++ (the default), Cygwin’s GCC, Borland C/C++ (really?), and MinGW32′s GCC. Using Microsoft’s compiler introduces some complexity, especially what version to install. Cygwin usually isn’t desirable as it introduces dependencies on Cygwin’s DLL. I personally don’t know anyone who uses Borland’s products any longer. That leaves MinGW as a sensible compiler.
At this point, I’ll assume that the reader has installed Simply Fortran. The package includes a fully configured and complete version of the MinGW-w64 GNU C, C++, and Fortran compilers. Additionally, the compilers will be added to the path, so typing gcc –version or gfortran –version at the Windows command prompt should present some compiler version information. Just having the compilers on the path overcomes one of the larger hurdles in setting up an environment for building Python extensions.
Next, let’s assume that the reader will be working with 32-bit Python on Windows. 64-bit Python on Windows is problematic in that the only supported compiler is Visual C++, adding some additional trouble. There is currently an enhancement ticket to support MinGW-w64 in the core Python bug tracker, but, at this time, it simply isn’t usable without some annoying steps. For most purposes, 32-bit Python should be sufficient (at least at the time of writing this post).
The first step is to direct Python’s distutils to always use Simply Fortran’s compiler. By default, building an extension via python setup.py build is going to result in a cryptic error about a batch file that implies something about Visual C++. To permanently direct Python to use Simply Fortran’s compiler, you’ll need to either create or edit a file at <Python Installation>\Lib\distutils\setup.cfg, adding the following:
This little addition directs Python to try to use MinGW32 compilers by default. However, some users may have noticed a discrepancy. In the setup.cfg file, we have instructed Python to use MinGW32′s GNU C compiler, but Simply Fortran provides a version of the MinGW-w64 GNU C compiler. The default output of Simply Fortran’s compiler will be 64-bit code, but we need to build 32-bit code in this described configuration.
The next step is to modify some of distutils code to account for our 64-bit compiler. The configuration of the MinGW32 compiler can be found in the file <Python Installation>\Lib\distutils\cygwinccompiler.py. Personally, I would suggest opening it with Simply Fortran as it understands Python code quite well. Next, search for “-mno-cygwin” in this file. This text is a somewhat dated compiler flag that instructs GNU compilers to avoid dependencies on Cygwin. MinGW-w64 compilers (and modern MinGW32 compilers, I believe) don’t understand this compiler option. In our case, though, we need to instruct the Simply Fortran compilers to build 32-bit code every time. This search gives us the opportunity to add the flag “-m32” to the compiler flags. My suggestion is to replace every occurrence of ”-mno-cygwin” with ”-m32” in cygwinccompiler.py. In Python 3.3, for example, there should be exactly five occurences, all in lines 296 through 300, in cygwinccompiler.py.
Before closing this file, one more change is necessary. The default configuration also instructs the compiler to link with the Microsoft Visual C runtime that matches with the version used to build the Python interpreter. Attempting to do this with Simply Fortran’s compiler will almost certainly fail. Instead, search for the following in cygwinccompiler.py:
self.dll_libraries = get_msvcr()
Change the above line to be:
self.dll_libraries =  #get_msvcr()
This change just removes the attempted linking with the Visual C++ runtime. Save cygwinccompiler.py and close the file.
Python should now be configured to build extensions. As a test, I suggest downloading the Python source archive and attempting to build the example in PC\example_nt. Type python setup.py build and watch as Simply Fortran’s compiler builds the C extension module. For a self-contained non-trivial example, try the crc16 module.
Readers might now be wondering about building NumPy or SciPy extensions (or SciPy itself). NumPy, however, has its own distutils configuration that requires modification. If you attempt to build a NumPy extension, things might seem to go well for a while, but it won’t exactly work. Setting up NumPy is a whole other article.