On Sun, Oct 26, 2014 at 10:41 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 26 October 2014 13:12, Tony Kelman <kel...@berkeley.edu> wrote: >> Only cross-compilation and the build system in the above list are relevant >> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are >> real reasons for some groups of users and developers to prefer MinGW-w64 >> over MSVC. > > Not really, to be honest. I still don't understand why anyone not > directly involved in CPython development would need to build their own > Python executable on Windows. Can you explain a single specific > situation where installing and using the python.org executable is not > possible (on the assumption that the mingw build is functionally > identical and ABI compatible with the CPython build, the claim being > made here)?
I don't know where this "ABI compatible" thing came into being; I think Steve Dower eluded to it by stating that we should focus on enabling MinGW-w64 as an extension-building compiler, using a core interpreter built with MSVC, and that by limiting the interfaces to the Windows C calling conventions everything would be OK. Unfortunately this is not possible. MinGW-w64-built extensions need to link to msvcrt.dll to do anything useful and you cannot mix two different msvcr??.dlls in one application. Please see http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=VS.100%29.aspx and http://msdn.microsoft.com/en-us/library/ms235460%28v=VS.100%29.aspx for the details. MinGW-w64 assumes the very old msvcrt.dll files from Windows XP SP3 and XP64 specifically to avoid this mess. The rest of your reply assumes that this ABI compatibility is a given so I'll stop at this point. > Note that "not possible" is different from "I don't want > to" or "it doesn't fit my views about free software" or similar. Also > note that building extensions is different - you have to assume that > building extensions using mingw with a mingw-built CPython is just as > hard as building them with a MSVC-built CPython (otherwise you've made > changes to extension building and you should contribute them > independently so that everyone can benefit, not just those who build > their own Python with mingw!) > >> Paul Moore: >>> If it were possible to cross-compile compatible extensions on Linux, >>> projects developed on Linux could supply Windows binaries much more >>> easily, which would be a huge benefit to the whole Windows Python >>> community. >> >> I want to do exactly this in an automated repeatable way, preferably on >> a build service. This seems harder to do when CPython cannot itself be >> built and handled as a dependency by that same automated, repeatable >> build service. > > I cannot see why you would need to build Python in order to build > extensions. After all, if your build service is on Linux, it couldn't > run a mingw-built Python anyway. If your build service is a Windows > machine, just install the python.org binaries (which is a simple > download and install, that can be fully automated, but which is a > one-off process anyway). > >> Unless it becomes possible to cross-compile extensions >> using the build machine's own version of Python, which might be the right >> approach. > > This may be where we are getting confused. I see this as the only > practical way of cross-compiling Windows extensions on Linux, by using > the Linux Python. So being able to cross-compile Python is not > relevant. > > On a tangential note, any work on supporting mingw builds and > cross-compilation should probably be done using setuptools, so that it > is external to the CPython code. That way (a) it isn't constrained by > the CPython release schedules and backward compatibility constraints, > and (b) it can be used in older versions of Python (which is pretty > much essential if it's to be useful, TBH). > > Paul _______________________________________________ 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