On Wed, Nov 11, 2009 at 11:22 PM, Robert Kern <robert.k...@gmail.com> wrote: [..] > To get to one real specific problem, let's consider build_src. build_src is > a new subcommand in numpy.distutils that builds C extension sources from > other files. We use this to hook in f2py's wrapper generator and other more > ad hoc forms of generating wrappers. When build_ext uses --inplace, we need > build_src to use --inplace, too, because it will often output some "final" > products in addition to intermediate wrapper sources. In order to integrate > this with setuptools' develop command (which invokes build_ext --inplace but > not build_src --inplace because setuptools knows nothing about > numpy.distutils), we need to create a subclass of setuptool's develop > command that will reinitialize build_src with the appropriate option. Then > we need to conditionally place the develop command into the set of command > classes so as not to introduce a setuptools dependency on those people who > don't want to use it. > > This is nuts.
This clearly indicates that we should be able to extend build_ext behaviour without subclassing it. And having the ability to drive a specific compiling from within an Extension subclass can solve this issue. > numpy.distutils shouldn't have to know anything about > setuptools to accomplish this if the framework were properly designed. And > this doesn't even get into the fact that many of the numpy.distutils command > classes that are shared with setuptools are conditional subclasses and > probably still buggily cobbled together. Same goes with "install", and I've proposed in the past the ability to run arbitrary commands as pre/post hooks for it. So we can "configure" this command instead of replacing it. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig