> But perhaps we could change the focus for 2.7 development a bit: > instead of fixing bugs (or bickering about whether something is a bug > fix or a new feature) we could limit changes to ensuring that it works > on newer platforms. Martin mentioned that building 2.7 for Windows > with the same toolchain that was used for the 2.7.0 release is getting > more and more problematic.
For Windows, I don't see a way to achieve this. With the current setup of the Microsoft C runtime library, we need to continue to build with VS 2008 "forever", in the 2.7 branch. While it would be possible to include project files for VS 2012 (and fix the few places where the code doesn't work on VS 2012), this wouldn't help: If we release 2.7.5 (say) built with VS 2012 (say), then existing third-party extension modules may break (depending how precisely they use the CRT). Likewise, if a user choses to rebuild Python with VS 2012 themselves, they really ought to rebuild all extension modules that they use as well. They probably won't recognize this requirement, and then debug difficult-to-understand issues. IOW, to update the tool chain, we would really have to call it python28.dll (or start with a new approach of calling it python27vs11.dll, which would create distinct universes where each extension needs to be built for each universe). So I believe that extension building is becoming more and more painful on Windows for Python 2.7 as time passes (and it is already way more painful than it is on Linux), and I see no way to do much about that. The "stable ABI" would have been a solution, but it's too late now for 2.7. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
