Leonard Ritter <cont...@leonard-ritter.com> added the comment: Hello everyone,
I'm seconding the wish to be able to build Python with MSYS on Win32, and I can give several technical reasons: It is my understanding that in order to build an extension for Python on Win32, one requires to use the same compiler as the one Python has been built with. Therefore, the choice of compiler affects not only Win32 developers working on the interpreter itself, but also developing and porting C/C++ based extensions. As of now, Microsoft has released its Visual C++ compiler in various versions, some free of cost (Express), some expensive (Studio). Express versions change every year, while Studio versions change every two years. Express versions supersede each other, so once a new version is available, the older version is virtually impossible to get. Python binary releases for Win32 use the Visual Studio 2005 compiler, which is not freely available, but must be bought. Right now, it's impossible to build an extension using distutils without hacking the VC builder a bit. VCExpress uses a slightly different registry layout for various settings, which causes the builder to fail. It takes considerable effort to keep Python/Win32 setup tools compatible for VC, and all this is done to support the native compiler sufficiently, a goal that appears to me more and more as an aesthetic choice rather than a practical one. A developer wishing to deploy Win32 binaries for his extensions is currently forced to go through above hurdles or eventually buy a Microsoft product to make the pain go away. Cross-building extensions for Python on Unix using Wine is impossible because no supported version of either VS or VC++ works. I call this a terrible situation. Cygwin is the second alternative. Building Python using Cygwin makes Python and all its extensions dependent on cygwin.dll, plus it's also, as far as I gather, imitating a Unix environment for runtimes, rather than a native Win32 one, which may cripple an applications abilities to adapt to its target platform. >From my perspective, MSYS does deliver. Resulting binaries depend only on available libraries coming with the OS. MSYS is practically available to everybody. MSYS also supports cross compiling, so Python binaries could even be built without Wine. On Windows, Eclipse CDT supports MSYS as a native backend. I would actually very much prefer if the default distribution of Python for Win32 were to use MSYS, but I understand that developers working on the Win32 platform prefer to use their native tools. It's also unnecessary, as you can gather from the following: I mainly develop games and multimedia applications on the Linux platform, for convenience reasons. Using MSYS, I could easily deploy a minimal custom-built version of Python with required extensions in one package, without any dependency on simulated unix enviroments. I could cross-build these apps on Linux, and test them for Win32 within Wine. If they work in Wine, they will definitely work on Windows. I would need neither a VC/VS nor a Windows license to support it. I call that a wonderful situation. <offtopic>LKCL: although you are clearly a mad scientist, please do continue your work. Do not get frustrated by ignorant responses and keep calm. You do pioneering, disruptive work, and such work will always be misunderstood and criticized because it requires a throughout understanding of future possibilities.</offtopic> Nevertheless, I see the feature you are trying to implement as trivial and self-explaining, something that should have been part of Python for a long time. People like me never took the time to file a ticket or make a comment though. We are busy bastards, I apologize. ---------- nosy: +lritter _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4954> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com