[Python-Dev] Status of C compilers for Python on Windows

[Ray Donnelly]

On Sat, Oct 25, 2014 at 6:13 PM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> (Apologies for the short reply, posting from my phone.)
>
> "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."
>
> Building CPython for Windows is not something that needs solving. The
> culture on Windows is to redistribute binaries, not source, and both the
> core team and a number of redistributors have this figured out (and it will
> only become easier with VC14 and Python 3.5).

This is the second time you've used the vacuous "culture on Windows"
argument, now with an added appeal to (vague) authority. That may be
your opinion and that of some others, but there's a large number of
people who don't care for using non-Free tools. IMHO building CPython
on Windows using Open Source toolchains is very much something that
needs merging upstream and supporting by default. What is it that you
are afraid of if CPython can be compiled out of the box using
mingw/MinGW-w64? Why are you fighting so hard against having option.
If CPython wants to truly call itself an Open Source project then I
consider being able to compile and cross-compile it with capable Open
Source toolchains on all major platforms a requirement.

>
> I'd rather see this effort thrown behind compiling extensions, including
> cross compilation. The ABI is well defined enough that any compiler should
> be usable, especially once the new CRT is in use. However, there is work
> needed to update the various tool chains to link to VC14's CRT and we need
> to figure out the inconsistencies between tools so we can document and work
> through them.
>
> Having different builds of CPython out there will only fragment the
> community and hurt extension authors far more than it may seem to help.
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> ________________________________
> From: Tony Kelman
> Sent: ‎10/‎25/‎2014 9:06
> To: python-dev at python.org
> Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
>
> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
>