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).