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 ./configure
you'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
signature.asc
Description: PGP signature
_______________________________________________ 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
