Ralf Gommers added the comment: A few comments from the perspective of what's needed for the scientific Python stack:
1. Of the three options mentioned in msg243605, it's definitely (3) that is of interest. We want to build extensions with MinGW-w64 that work with the standard MSVC Python builds. We've done this with mingw32 for a very long time (which works fine); not being able to do this for 64-bit extensions is the main reason why there are no official 64-bit Windows installers for Numpy, Scipy, etc. 2. There is work ongoing on a mingw-w64 toolchain that would work for the scientific Python stack: https://github.com/numpy/numpy/wiki/Mingw-static-toolchain. It actually works pretty well today, what needs to be sorted out is ensuring long-term maintainability. More details about what it's based on are provided in https://github.com/numpy/numpy/wiki/Mingw-w64-faq - I think it's consistent with what Ruben van Boxem recommends. Carl Kleffner, who has done a lot of the heavy lifting on this toolchain, is working with upstream mingw-w64 and with WinPython to ensure not creating yet another incompatible flavor mingw. 3. It's good to realize why making mingw-w64 work is especially important for the scientific Python stack: there's a lot of Fortran code in packages like Scipy, for which there is no free compiler that works with MSVC. So one could use MSVC + ifort + Intel MKL (which is what Enthought Canopy and Continuum Anaconda do), but that's quite expensive and therefore not a good solution for the many of contributors to the core scientific Python stack nor okay from the point of view of needing to provide official binaries that can be redistributed. Paul's comments on picking a single mingw-w64 version, and that version not being a download from someone's personal homepage, make a lot of sense to me. We (Carl & several core numpy/scipy/scikit-learn devs) happened to have planned a call on this topic soon in order to move towards a long-term sustainable plan. I wouldn't expect everything to be sorted out in a couple of weeks (it's indeed a hard goal), but knowing that Paul is willing to review and merge patches definitely helps. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4709> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
