Greg Ewing schrieb:
> Not sure exactly what you mean by a "sub-command".
> If you mean a subclass of the class that implements
> the "build" command, that's far too heavyweight.
distutils has a special concept called a "subcommand"
(apparently, people creating such packages have an
intuition for creating hard-to-understand terms for
concepts).
Executing a command (such as build) split into
multiple sub-commands (build_py, build_ext, ...).
Invoking the build command will invoke all its
subcommands. For pyrex, creating a build_pyx command
might be appropriate.
> I want to deal just with the .pyx->.c transformation,
> and not have to worry that I might mess up something
> else that the build class does.
And you don't need to. The build command itself does nearly
nothing; it's all in the sub-commands.
You still have to override the build class, to rewrite
the get_sub_commands methods. Actually, just
providing a sub_commands attribute would be enough:
class BuildWithPyx(build):
sub_commands = [('build_pyx', 'compile Pyrex files')
] + build.sub_commands
> Also, what happens if I want to use my extended
> build class together with someone else's extended
> build class? Do I have to merge them using multiple
> inheritance?
If they also created a new sub-command for build,
you would have to make your get_sub_command implementation
return them both.
> Without knowing a *lot* about their
> internals, I'd be very nervous doing that lest they
> interact in unforeseen ways.
The sub-command acts on its own, and you don't interfere
with it. The order of sub-commands may matter: you likely
would run the build_pyx sub-command before build_ext,
e.g. by adding it at the beginning
> It *doesn't* generate any warnings using the
> normal, default C compiler settings -- only the
> extremely paranoid ones that the Python installation
> defaults to.
It uses -Wall -Wstrict-prototypes. That's *not*
"extremely paranoid". It is standard in any reasonable
C project.
> If I were dealing with a Makefile, and there
> weren't a macro to override that would have the
> desired effect, I could replace the whole rule
> for linking C files with one of my own that
> did whatever I wanted.
So extra_link_args for the Extension objects didn't
work for you?
> Then we seem to have a difference of opinion on
> what the basic architecture should be like. I
> think it should be more like Make, and I don't
> see a way of getting there from here incrementally.
Right. It's currently not declarative; it's primarily
imperative (at least wrt. how the build steps work,
not wrt. what is being built).
It would be possible to integrate declarative
features for the build steps also (like what you
wanted for the link step); to do that, some
dependency machinery (like SCons or zc.something)
could be integrated as the back-end for the
build steps.
Regards,
Martin
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
