> 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 ?