Tarek Ziadé <ziade.ta...@gmail.com> added the comment: > 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 problem I see is that sometimes, people are using the build_ext command on its own: $ python setup.py build_ext -i --compiler mingw32 So that means build_ext is not a subcommand of build in this case. While we can instanciate a build command on the fly to get our compiler and work with it, using get_command_obj(). But the code will have to be careful and not use the cache with this method e.g. to re-create a new build command to avoid using the same command instance if another build_ is called. What about making it all simpler, by creating a base command class that manages a compiler through some methods (like get_compiler_obj), then make all our build+build_* command inherit from it ? That would resolve the code duplication and will make it simpler each command to deal with a compiler. This base command would have one single option. e.g. "compiler" > 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 I am not sure to understand how .compiler will become a string again after .finalize_options() has been called. Could you provide an example ? ---------- _______________________________________ 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
