Marc-Andre Lemburg <m...@egenix.com> added the comment: Tarek Ziadé wrote: >> 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.
It is generally a bad idea to mix compiler types when compiling Python extensions and usually doesn't work unless you are very careful. In practice, I don't think that any extension package will use more than one compiler type for the various build parts. However, it is well possible that a package may use differently setup compiler instances on various commands, e.g. to point it to different libraries, dirs, etc., so having just one such instance on e.g. the top-level build command object would not work out. In fact, a single command object may even use multiple compiler instances to e.g. build different C libs or extensions using different sets of include and library search dirs. I think a workable solution to the problem with the compiler option would be to remove the option from the build_ext, build_clib and config commands (plus any others, if there are more) and only allow it on the build command. The build.get_compiler_object() could then return an instance of the chosen compiler type and the command object would then store it in .compiler. The various .finalize_options() method would need to propagate any used "compiler" option back to the build command and reset the .compiler attribute to None. You'd still have the situation that .compiler is used as option string and then as compiler instance, but only for the short phase between .initialize_options() and .finalize_options() which is not all that much of a problem (you cannot make any use of non-finalized command objects anyway). ---------- _______________________________________ 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
