On Thu, Mar 6, 2008 at 3:52 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Mingw tends to be rather more stable (though not itself without the > occasional library compatibility issue), and more freely available.
Not all extensions can be built using mingw (pywin32 comes to mind immediately). And while you can almost easily (but not very easily, since you need to patch libmoldname yourself and then update your spec file) change runtime used by mingw, you cannot do so with Visual Studio. Besides, this would require spec-editing on both, build machines, as well as user machines (otherwise you get extensions that depend on both msvcrt.dll and msvcrXX.dll), this is a complication too. Runtime compatibility could be a potential problem (or maybe not, if WITH_PYMALLOC maybe fixes that?), so official mingw port (as much as I'd like for one to be there) does not seem feasible to me in any future, Python is already too far on the needle of Visual Studio. :( The biggest problem would also be with some extensions' setup.py. Many extensions I've seen hardwire to distutils.msvccompiler in one way or another. If official python would shift to mingw, they would suddenly break. I think the best lesson here is Tcl. Because it uses stubs mechanism, you don't need to depend on tclXX.dll, you don't deal with really direct implementation details, you don't care about runtimes, everything is much easier. Maybe it's possible (and not too late) for Python to somehow embrace such mechanism? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
