On 10/10/2014 08:07 AM, Paul Moore wrote:
On 10 October 2014 01:29, Victor Stinner <victor.stin...@gmail.com> wrote:
What about the Python stable ABI? Would it be broken if we use a
different compiler?
What about third party Python extensions?
What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.?
The key point for me is that any supported build on Windows supports
the exact same ABI.
Just to make something clear that may not be clear to non-Windows
developers: the C library is implicitly part of the ABI. So unless
these other compilers bend over backwards to generate code / have a C
library that behaves *exactly* like MSVC, their ABI will be different,
and therefore shared libraries compiled with one compiler won't work
with the next. Heck, even shared libraries compiled with one version of
MSVC won't work with any other version! (This is something apparently
being fixed by MSVC 15; apparently they are designing the ABI for
forwards compatibility. Huzzah!)
So if CPython officially said "we support MSVC and Compiler X", I worry
that we'd have third-party modules compiled with either one or the
other, leaving users unable to mix and match third-party extensions as
they do today. ("I want to use library X, which is only available
compiled by MSVC. I also want to use library Y, which is only available
compiled by Compiler X. What should I do?" "... install Linux?")
Here's my perspective. Having your code compilable by more compilers is
good. But a maze of #ifdefs is bad. We still have #ifdef's for Borland
C--I'd be very surprised if anyone was compiling Python 3 with Borland
C. IMO the benefit from supporting other compilers on Windows is
negligible, but the costs in maintaining these other compilers is
tangible. Or, worse, we accept changes to support these other
compilers, but the support is incomplete, or goes unmaintained and
breaks (and nobody notices).
So as a practical matter I think I'd prefer if we continued to only
support MSVC. In fact I'd prefer it if we removed support for other
Windows compilers, instead asking those maintainers to publish their own
patches / repos, in the way that Stackless does.
//arry/
_______________________________________________
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
