Martin v. Löwis wrote: > 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. > 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 This is another problem. The order in which things are done, and whether things are done at all, should be driven by the dependency graph. You shouldn't have to program it explicitly. > It uses -Wall -Wstrict-prototypes. That's *not* > "extremely paranoid". It is standard in any reasonable > C project. 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. It serves no useful purpose to complain about things like unused variables and labels when the C compiler is quite capable of optimising them away, thus saving the Pyrex compiler from having to do that itself. > So extra_link_args for the Extension objects didn't > work for you? No. Like I said, there are circumstances in which the -F options need to go at the beginning of the link command, but the extra_link_args get put at the end. 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. > 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. 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? -- Greg _______________________________________________ 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
