I'm several weeks late to this discussion, but I'm glad to see that it happened. I'm not a Python developer, and barely a user, but I have several years of daily experience compiling complicated scientific software cross- platform, particularly with MinGW-w64 for Windows. The Python community, both core language and scientific package developers and users, needs to act here. The problem is bad and getting worse. Luckily much of the work to start solving it has already been done in bits and pieces, it needs coordination and participation to come to a conclusion.
Cross compilation is a valid issue, but I hope that build services like Appveyor also help out here. There is regular talk about the PSF/PyPI providing something similar
AppVeyor is better than nothing (I've been using it since beta), but it's a far cry from build services and package management as the Linux world knows them. Obtaining and setting up build dependencies quickly and repeatably, and finishing the build of a complicated piece of software such as CPython, or NumPy, SciPy, Julia (where most of my recent expertise lies), etc. on a small single-core VM with limited memory and a restrictive time limit is often not possible. These problems are solved within Linux infrastructure like Koji, Open Build Service, buildd, etc. MinGW-w64 is a mature, well-tested toolchain that is very capable of cross- compiling a wide variety of libraries from Linux to Windows, in addition to building conventionally on Windows for Windows. The MSYS2 collection of MinGW-w64-compiled packages (https://github.com/Alexpux/MINGW-packages) has been mentioned. Linux distributions including - Fedora https://admin.fedoraproject.org/pkgdb/packages/mingw%2A/ - openSUSE https://build.opensuse.org/project/show/windows:mingw:win32 - Arch https://aur.archlinux.org/packages/?K=mingw and others have projects for providing many hundreds of open-source packages compiled for Windows. Debian has the cross-compilers available but not many packages yet (https://packages.debian.org/search?keywords=mingw). As a developer of a (compiled) open-source library or application, wouldn't you love to be able to build binaries on Linux for Windows? With some work and build system patches, you can. For many projects it's a simple matter of ./configure --host=x86_64-w64-mingw32. Not with CPython though. CPython is only included in 2 of the above MinGW-w64 distribution projects, MSYS2 and Arch. This is possible with a very, very long set of patches, many of which have been submitted by Roumen Petrov to the Python bug tracker - see http://bugs.python.org/issue17605 and other issues linked therein. Roumen has done a huge amount of work, and he and others who consider the MinGW-w64 compiler important will continue to do so. (Thanks a million Roumen!)
I could step in as maintainer for Cygwin and builds based on GCC using mingw* APIs. Regards, Roumen Petrov
A maintainer has volunteered. Others will help. Can any core developers please begin reviewing some of his patches? Even if just to say they need to be rebased. The lack of responses on the bug tracker is disheartening from an outside perspective. The pile of patches accumulating in external MinGW packaging projects is tantamount to a fork of CPython. It won't go away since there are dedicated packagers working to keep their MinGW-w64 builds functional, even in the ad-hoc current state. The patches continue piling up, making it more difficult for everyone - except for the core Python developers if they continue to ignore the problem. Bring the people working on these patches into the fold as contributors. Review the patches. It would make Python as a language and a community even more diverse and welcoming.
Deprecate/remove support for compiling CPython itself with compilers other than MSVC on Windows
I'm not alone in thinking that this would be a bad idea. MSVC can continue to be the default compiler used for Python on Windows, none of Roumen's patches change that. They would merely open up the choice for packagers and users to build CPython (and extension modules, thanks to separate patches) with alternate compilers, in cross-compilation or otherwise. Sincerely, Tony _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com