Jon added the comment: [Eric] >> This is about mingw, which is the **main free software that builds >> executables on Windows**. You know, for when you don't want to require >> your users to install Visual Studio. > Let me state that I fully sympathize with people who use Windows and > still want to use free software as much as possible, even though some > version of Visual Studio is now available at no cost. Again, the > fact is that many core developers don’t use Windows, and the official > CPython builds use MSVC, so from this viewpoint, MinGW is a niche > platform for CPython. It does not mean that patches are rejected, > just that it’s harder for me to assess them.
I'm going to advocate why mingw-based toolchains (mingw.org and mingw-w64) should be considered important platforms for CPython by giving some background info. An important part of this issue has nothing to do with the politics of "free software" and everything to do with the technical benefits of using mingw-based toolchains on Windows. While you may be aware of the technical benefits, the following are important to me: 1a) MSVC forces you to link against a specific CRT version, and I don't get to decide which CRT version via a build setting. To the best of my knowledge the only way to link against another CRT version is to use another MSVC version. Many times it's important for all parts of a codebase to link against the same CRT version to prevent well-known cross-CRT object usage failures. While Mingw toolchains typically link to msvcrt.dll by default, they allow you to specify a CRT version via spec file tweaks. 1b) Often the most practical/stable way to build mixed codebases using CRT functionality is to link everything against msvcrt.dll. Using MSVC, the only way I'm aware of is to use old-and-slow VC6 which is not easily available. Updated and performant mingw toolchains enable one to link against msvcrt.dll and other CRT versions via spec file hackery. 2) While VC++ is a good IDE, many of us would like to simply use the command line compiler tools and not clutter our environment with a huge IDE we never use. MSFT has a poor record on this front, and after many fine years of making the command line tools available as part of the Windows SDK, they've regressed back to their lame ways in Windows 8 by removing the cmd line compiler tools from the SDK and embedding into the IDE similar to the old VC6 days. Enticing as it may be, I'll stop here rather than lurch into sailor-speak rage rant. There are other benefits, but (1a) and (1b) are very important for many real-world usage scenarios on Windows. For example, easily building mercurial with mingw on Windows that work with the official MSVC-built Python. Extend this to other widely used Python and non-Python libraries. Extend this to those building binary libraries on Linux/OSX via mingw for their Windows users. Also, there are other build automation awesomeness things you can do with mingw toolchains. For example, wouldn't it be great if you could download your source software, a complete mingw toolchain, and build the software on Windows in a sandbox using the mingw toolchain? You can with mingw and mingw-w64 toolchains. Nothing to pre-install and highly automated with minimal user intervention. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12641> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
