Pyrex and Distuils: an enhanced build_ext command
Thomas Heller
theller at python.net
Wed Jul 10 07:38:19 EDT 2002
"Graham Fawcett" <gmfawcett at operamail.com> wrote in message news:3d799735.0207100216.4eb8a9cd at posting.google.com...
>
> Okay, I wrote the distutils command. Actually I just added a
> subpackage to Pyrex that you can import into your setup script:
>
> from distutils.core import setup
> from distutils.extension import Extension
> import Pyrex.Distutils
>
> setup(name='foo', ext_modules=[Extension("foo", ["foo.pyx"])])
>
> Note that the Extension() specifies a .pyx file, not a .c file. You
> can specify .c files as well, but of course Pyrex will ignore them.
>
> Pyrex.Distuils (my subpackage) is a build_ext replacement -- it
> import-hacks itself into the distutils.command package, so that it
> gets a first shot at any build_ext calls. Once it's finished, it
> returns control to the "real" build_ext.
Some notes, just to spread some distutils knowledge:
1. The 'official' way to replace a standard distutils command
class is done in the following way: Derive your class, say
'my_build_ext', from the standard distutils command:
class my_build_ext(build_ext):
....
and then pass a cmdclass parameter to the setup command:
setup(...
cmdclass = {'build_ext': my_build_ext},
...)
2. Looking at distutils command.build_ext source, there is already
a method which 'precompiles' source files into .c files, it's the
swig_sources() method. Sound a little hackish, but probably we could
get away with just overriding this method in the my_build_ext class.
Maybe something like the swig_sources() command should be promoted
into an 'official' hook for precompilation?
Thomas
More information about the Python-list
mailing list