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