Tarek Ziadé <ziade.ta...@gmail.com> added the comment: > You never run a command twice unless you explicitly reinitialize it > (which then resets .compiler to None and then fetches the command line > option again), so the above is not a problem.
In practice yes that's true. > The "compiler" option on the build_ext and config commands > are not really needed. Their .finalize_options() methods could > easily pull in the build option value and place it into > an .compiler_type attribute which then gets used as basis for > creating the .compiler instance, or even better refactor the > various commands to use a central method on the build > command object to create a compiler object and avoid all > the copy&paste code for this. > Furthermore, the .finalize_options() methods could detect whether > a per-command option as used and deprecate this use instead, > redirecting to the build command option. Having a single location sounds like the best idea with the current behavior, reachable from cmd.get_compiler_object() like you did. Now the question is, in practice, could someone force a different compiler in build_ext for instance, or with a different configuration than in build_clib ? I don't see a use case in practice for that, but if so, we would need to keep a different compiler instance per command. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
