[Python-Dev] versioned .so files for Python 3.2 (original) (raw)
Barry Warsaw barry at python.org
Thu Jun 24 23:23:02 CEST 2010
- Previous message: [Python-Dev] versioned .so files for Python 3.2
- Next message: [Python-Dev] versioned .so files for Python 3.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Jun 24, 2010, at 08:50 PM, Éric Araujo wrote:
Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
Other possible approaches: * Extend the distutils API so that the .so file extension can be passed in, instead of being essentially hardcoded to what Python's Makefile contains. Third-party code rely on Distutils internal quirks, so it’s frozen. Feel free to open a bug against Distutils2 on the Python tracker if that would be generally useful.
Depending on how strict this constraint is, it could make things more difficult. I can control what shared library file names Python will load statically, but in order to support PEP 384 I think I need to be able to control what file extensions build_ext writes.
My updated patch does this in a backward compatible way. Of course, distutils hacks have their tentacles all up in the distutils internals, so maybe my patch will break something after all. I can think of a few even hackier ways to work around that if necessary.
My updated patch:
- Adds an optional argument to build_ext.get_ext_fullpath() and build_ext.get_ext_filename(). This extra argument is the Extension instance being built. (Boy, just in case anyone's already playing with the time machine, it sure would have been nice if these methods had originally just taken the Extension instance and dug out ext.name instead of passing the string in.)
- Adds an optional new keyword argument to the Extension class, called so_abi_tag. If given, this overrides the Makefile $SO variable extension.
What this means is that with no changes, a non-PEP 384 compliant extension module wouldn't have to change anything:
setup( name='stupid', version='0.0', packages=['stupid', 'stupid.tests'], ext_modules=[Extension('_stupid', ['src/stupid.c'], )], test_suite='stupid.tests', )
With a Python built like so:
% SOABI=cpython-32 ./configureyou'd end up with a _stupid.cpython-32.so module.
However, if you knew your extension module was PEP 384 compliant, and could be shared on >=Python 3.2, you would do:
setup( name='stupid', version='0.0', packages=['stupid', 'stupid.tests'], ext_modules=[Extension('_stupid', ['src/stupid.c'], so_abi_tag='', )], test_suite='stupid.tests', )
and now you'd end up with _stupid.so, which I propose to mean it's PEP 384 ABI compliant. (There may not be any other use case than so_abi_tag='' or so_abi_tag=None, in which case, the Extension keyword might be better off as a boolean.)
Now of course PEP 384 isn't implemented, so it's a bit of a moot point. But if some form of versioned .so file naming is accepted for Python 3.2, I'll update PEP 384 with possible solutions.
-Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100624/14b9b0be/attachment.pgp>
- Previous message: [Python-Dev] versioned .so files for Python 3.2
- Next message: [Python-Dev] versioned .so files for Python 3.2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]