Greg Ewing schrieb: >> If they also created a new sub-command for build, >> you would have to make your get_sub_command implementation >> return them both. > > If these sub-commands really are independent, > why can't I just add one to a list somewhere? > Then it would be no problem at all for different > extensions to coexist.
You can, sure. distutils.commands.build.sub_commands. To do so, you either have to edit the source code of build.py, or you have to arrange that the addition is done programmatically somehow when setup.py runs. > It might be considered reasonable for human-written > code, but it's not reasonable to expect machine > generated code to pass such a strict test. Given that it is *generated* code, I find that very reasonable. Just fix the generator once, and the warnings will go away. For hand-written code, any new piece of code might cause a new warning. For generated code, because of the systematic way, the warnings can be removed in the generator, not in the input (the pyx file). I've been writing generators that produce C++ for years, and never found it a problem make it write warning-less, legible code. > The point about this is that no matter how many > options you provide to a command, there will always > be circumstances in which they're not sufficient. > So there needs to be a clear and understandable > way to override anything at any stage in the > process. Ah, ok. So you'd want a "build command override" for an extension object. Such a feature could be added to distutils. > And if you're doing that, why bother with the > build steps layer at all? Why not just let the > user specify the dependency graph directly and > let it rip? build_py, for example, *only* copies the source files into the build tree (with time stamp checking). The user shouldn't have to specify this, because a) it is tedious and error-prone to do so for each source file, and b) you can't know in a static way what the target directory is, because the platform name goes into the target name. 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
