Deprecate support for mingw - add to PEP 11

I think perhaps we should admit that this build system is no longer supported. From everything I can tell, the mingw project is no longer maintained. The project's site, mingw.org, is no longer live; the project on sourceforge, although still downloaded daily, had its last commit almost 3 years ago - a commit which changed the official project URI to a new link that now is also dead. Looking over BPO there are a little over 50 bugs open against mingw, but only 7 that have any meaningful activity within the last three years. Three of those issues explicitly mention mingw-w64 which is an active fork of the original mingw project (active homepage, commits almost daily, new release within the last 6 months) and I wonder if this is the project the other 4 projects meant by "mingw"? Ideally any features and flags in the code base for mingw would be checked to already be working with mingw-w64 or else modified to work, but this would require a sponsor for this platform, which appears to be missing. Further, there is no buildbot for mingw, which should be a requirement to be a fully supported platform, as per this PEP. This potential work appears non-trivial with a cursory look at the mingw-w64-python pacman project, which contains close to 100 patch files. I am purposing instead that mingw be deprecated and, if a sponsor comes along, mingw-w64 can become re-supported, or newly supported depending on you point of view, as allowed by the PEP.

mingw-w64 might be a small change. But while one is it at, it might make sense to evaluate: https://clang.llvm.org/docs/MSVCCompatibility.html Apparently clang on Windows is working on calling convention compatibility with Visual Studio. On Sat, Feb 20, 2021 at 8:37 PM <ucodery@gmail.com> wrote:

It looks like CPython remains 100% C, so clang becomes more attractive: https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binar... Then again, do we allow C++ extension modules? That might make C++ more relevant, even if CPython itself is purely C. On Sat, Feb 20, 2021 at 9:08 PM Dan Stromberg <drsalists@gmail.com> wrote:

On Sun, Feb 21, 2021 at 10:02 AM Dan Stromberg <drsalists@gmail.com> wrote:
Extensions can easily be built in any language, C++ is even documented, and I've built a simple one in Rust when I was learning it -- as long as you use the equivalent of extern "C" { } for that language, or rebuild the headers you need in another language (quite an undertaking, admittedly, even with a header parser). The line "You will still need the C compiler that was used to build Python; typically Microsoft Visual C++." hasn't been accurate in a long time either (it's been in there since Python 2.2, when VC++ 6.0 was the latest, which had quite a few... quirks), anything that can digest the headers can link via the C API just fine. I guess since it's just not tested or supported, so you're on your own if you run into any issues with memory management, threading conflicts, compiler bugs, header conversion issues, etc. -Em

pybind11 is a famous C++ extension module for Python. Yes, the Python C API is usable in C++ thanks to extern "C" { ... } being used in headers. Victor On Sun, Feb 21, 2021 at 6:59 PM Dan Stromberg <drsalists@gmail.com> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.

In case anyone is wondering what mingw-w64-python is referring to: https://packages.msys2.org/base/mingw-w64-python The MSYS2 project [0] maintains a CPython variant that builds with gcc/clang+mingw-w64 on Windows. We lack the manpower to reduce the diff to upstream though. The yearly rebuilds, the move to isolated builds and the move away from distutils keeps us busy. But if anyone wants to help you now know where to find us. [0] https://www.msys2.org/

mingw-w64 might be a small change. But while one is it at, it might make sense to evaluate: https://clang.llvm.org/docs/MSVCCompatibility.html Apparently clang on Windows is working on calling convention compatibility with Visual Studio. On Sat, Feb 20, 2021 at 8:37 PM <ucodery@gmail.com> wrote:

It looks like CPython remains 100% C, so clang becomes more attractive: https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binar... Then again, do we allow C++ extension modules? That might make C++ more relevant, even if CPython itself is purely C. On Sat, Feb 20, 2021 at 9:08 PM Dan Stromberg <drsalists@gmail.com> wrote:

On Sun, Feb 21, 2021 at 10:02 AM Dan Stromberg <drsalists@gmail.com> wrote:
Extensions can easily be built in any language, C++ is even documented, and I've built a simple one in Rust when I was learning it -- as long as you use the equivalent of extern "C" { } for that language, or rebuild the headers you need in another language (quite an undertaking, admittedly, even with a header parser). The line "You will still need the C compiler that was used to build Python; typically Microsoft Visual C++." hasn't been accurate in a long time either (it's been in there since Python 2.2, when VC++ 6.0 was the latest, which had quite a few... quirks), anything that can digest the headers can link via the C API just fine. I guess since it's just not tested or supported, so you're on your own if you run into any issues with memory management, threading conflicts, compiler bugs, header conversion issues, etc. -Em

pybind11 is a famous C++ extension module for Python. Yes, the Python C API is usable in C++ thanks to extern "C" { ... } being used in headers. Victor On Sun, Feb 21, 2021 at 6:59 PM Dan Stromberg <drsalists@gmail.com> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.

In case anyone is wondering what mingw-w64-python is referring to: https://packages.msys2.org/base/mingw-w64-python The MSYS2 project [0] maintains a CPython variant that builds with gcc/clang+mingw-w64 on Windows. We lack the manpower to reduce the diff to upstream though. The yearly rebuilds, the move to isolated builds and the move away from distutils keeps us busy. But if anyone wants to help you now know where to find us. [0] https://www.msys2.org/
participants (5)
-
Dan Stromberg
-
Emily Bowman
-
reiter.christoph@gmail.com
-
ucodery@gmail.com
-
Victor Stinner