<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">(Apologies for the short reply, posting from my phone.)<br>
<br>
"MSVC can continue<br>
to be the default compiler used for Python on Windows, none of Roumen's<br>
patches change that. They would merely open up the choice for packagers and<br>
users to build CPython (and extension modules, thanks to separate patches)<br>
with alternate compilers, in cross-compilation or otherwise."<br>
<br>
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).<br>
<br>
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.<br>
<br>
Having different builds of CPython out there will only fragment the community and hurt extension authors far more than it may seem to help.<br>
<br>
Cheers,<br>
Steve<br>
<br>
Top-posted from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:kelman@berkeley.edu">Tony Kelman</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">ý10/ý25/ý2014 9:06</span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:python-dev@python.org">python-dev@python.org</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">Re: [Python-Dev] Status of C compilers for Python on Windows</span><br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">I'm several weeks late to this discussion, but I'm glad to see that it<br>
happened. I'm not a Python developer, and barely a user, but I have several<br>
years of daily experience compiling complicated scientific software cross-<br>
platform, particularly with MinGW-w64 for Windows. The Python community,<br>
both core language and scientific package developers and users, needs to<br>
act here. The problem is bad and getting worse. Luckily much of the work<br>
to start solving it has already been done in bits and pieces, it needs<br>
coordination and participation to come to a conclusion.<br>
<br>
> Cross compilation is a valid issue, but I hope that build services like<br>
> Appveyor also help out here. There is regular talk about the PSF/PyPI<br>
> providing something similar<br>
<br>
AppVeyor is better than nothing (I've been using it since beta), but it's<br>
a far cry from build services and package management as the Linux world<br>
knows them. Obtaining and setting up build dependencies quickly and<br>
repeatably, and finishing the build of a complicated piece of software<br>
such as CPython, or NumPy, SciPy, Julia (where most of my recent expertise<br>
lies), etc. on a small single-core VM with limited memory and a restrictive<br>
time limit is often not possible. These problems are solved within Linux<br>
infrastructure like Koji, Open Build Service, buildd, etc.<br>
<br>
MinGW-w64 is a mature, well-tested toolchain that is very capable of cross-<br>
compiling a wide variety of libraries from Linux to Windows, in addition to<br>
building conventionally on Windows for Windows. The MSYS2 collection of<br>
MinGW-w64-compiled packages (<a href="https://github.com/Alexpux/MINGW-packages">https://github.com/Alexpux/MINGW-packages</a>) has<br>
been mentioned. Linux distributions including<br>
- Fedora <a href="https://admin.fedoraproject.org/pkgdb/packages/mingw%2A/">https://admin.fedoraproject.org/pkgdb/packages/mingw%2A/</a><br>
- openSUSE <a href="https://build.opensuse.org/project/show/windows:mingw:win32">
https://build.opensuse.org/project/show/windows:mingw:win32</a><br>
- Arch <a href="https://aur.archlinux.org/packages/?K=mingw">https://aur.archlinux.org/packages/?K=mingw</a><br>
and others have projects for providing many hundreds of open-source<br>
packages compiled for Windows. Debian has the cross-compilers available but<br>
not many packages yet (<a href="https://packages.debian.org/search?keywords=mingw">https://packages.debian.org/search?keywords=mingw</a>).<br>
<br>
As a developer of a (compiled) open-source library or application, wouldn't<br>
you love to be able to build binaries on Linux for Windows? With some work<br>
and build system patches, you can. For many projects it's a simple matter of<br>
./configure --host=x86_64-w64-mingw32. Not with CPython though. CPython is<br>
only included in 2 of the above MinGW-w64 distribution projects, MSYS2 and<br>
Arch. This is possible with a very, very long set of patches, many of which<br>
have been submitted by Roumen Petrov to the Python bug tracker - see<br>
<a href="http://bugs.python.org/issue17605">http://bugs.python.org/issue17605</a> and other issues linked therein. Roumen<br>
has done a huge amount of work, and he and others who consider the MinGW-w64<br>
compiler important will continue to do so. (Thanks a million Roumen!)<br>
<br>
> I could step in as maintainer for Cygwin and builds based on GCC using<br>
> mingw* APIs.<br>
><br>
> Regards,<br>
> Roumen Petrov<br>
<br>
A maintainer has volunteered. Others will help. Can any core developers<br>
please begin reviewing some of his patches? Even if just to say they need<br>
to be rebased. The lack of responses on the bug tracker is disheartening<br>
from an outside perspective. The pile of patches accumulating in external<br>
MinGW packaging projects is tantamount to a fork of CPython. It won't go<br>
away since there are dedicated packagers working to keep their MinGW-w64<br>
builds functional, even in the ad-hoc current state. The patches continue<br>
piling up, making it more difficult for everyone - except for the core<br>
Python developers if they continue to ignore the problem. Bring the people<br>
working on these patches into the fold as contributors. Review the patches.<br>
It would make Python as a language and a community even more diverse and<br>
welcoming.<br>
<br>
> Deprecate/remove support for compiling CPython itself with compilers<br>
> other than MSVC on Windows<br>
<br>
I'm not alone in thinking that this would be a bad idea. MSVC can continue<br>
to be the default compiler used for Python on Windows, none of Roumen's<br>
patches change that. They would merely open up the choice for packagers and<br>
users to build CPython (and extension modules, thanks to separate patches)<br>
with alternate compilers, in cross-compilation or otherwise.<br>
<br>
Sincerely,<br>
Tony<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
Python-Dev@python.org<br>
<a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com">
https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com</a><br>
</div>
</span></font>
</body>
</html>