[issue22980] C extension naming doesn't take bitness into account

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 16.04.2015 17:30, Matthias Klose wrote:
> 
> Matthias Klose added the comment:
> 
> Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. 
> 
> What you describe as a "simple idea" is just another hack, only addressing the issue on x86 platforms, not addressing this for soft-float/hard-float calling conventions, not addressing this for endianness, not addressing this for other platform ABIs. And for all these cases there are machines where you can run the variants on the same machine.  If you like to call this "a mess", fine. But this is reality.  I'm not creating this mess,  I'm describing this and exposing it to the interpreter.

The simple idea Antoine had was to be able to install C extensions
compiled for different bit architectures, but the *same platform*
into the same directory, which is similar to what we're doing for
Python byte code files.

The typical use case is to have a 32-bit version and a 64-bit version
on the same system.

It seems that the scope of this simple idea has now completely
blown up in trying to stuff all kinds of other platform features
into the binary names as well.

And while doing so, we now have different naming styles on different
platforms, require hand written configure files to support additional
platforms, and have yet another system for associating platform
information with binary Python files, in addition to
PEP 3149, PEP 425 and PEP 427.

See http://bugs.python.org/issue22980#msg232729

I don't think this is a good development and I can hardly imagine
a use case where all those different ABIs will have to live on the
same machine and in the same directory.

At the same time you are creating incompatibilities which did
not exist before, by requiring configure script fixes for "unknown"
platforms.

I'm -1 on these changes. I was +0 on Antoine's original idea,
since that addresses real life use case you can run into every
now and then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22980>
_______________________________________