"Jeremy Hylton"
We added an extra sanity check that was intended to guard against someone using a Python built with MSVC 6, say, and a DLL built with MSVC 7. The sanity check is that distutils finds out what compiler was used to build Python, and won't compile extensions with anything else. (I think I added this code.)
Er... I can build extensions quite happily with the mingw32 compiler, against a stock Python 2.3 for Windows.
When I was working on this, I was not even aware of the --compiler option. I don't know how dangerous it is to use DLLs from one compiler with a Python from a different compiler. I believe David Abrahams was involved in those discussions, and I've seen him here; perhaps he can offer an explanation.
Code compiled with mingw32 is, by default, compatible with Python built with MSVC6 (both link to msvcrt.dll). There would be incompatibilities if Python was built with MSVC7, as this uses a different C runtime DLL, but it should be possible to supply suitable command line options to the mingw32 compiler to allow compatible extensions to be built. Indeed, I have committed to making sure that happens - although I have no way of doing so until I have access to a Python built with MSVC7 (I don't have that compiler myself, and am not likely to get it).
Assuming it is safe to change compilers, it sounds like we need a patch to get 2.3 distutils working with custom compilers. I've never used a compiler other than MSVC on Windows, so I can't be of much help. I can merely confirm it doesn't break things for MSVC.
As I say, --compiler=mingw32 works fine with the distributed Python 2.3 binary. I imagine that it won't (either the build fails, or the extension is incompatible) with a custom-built-with-MSVC7 Python. Don't "fix" this, please! It would be a real problem if users couldn't build C extensions with free tools, without having to build the whole Python interpreter as well. Paul. -- This signature intentionally left blank