Tarek Ziadé wrote:
> Tarek Ziadé <ziade.tarek@gmail.com> added the comment:
> 
> The build_ext command cannot be run twice, because the first time, the
> "compiler" option may be set to "unix" for example, or left to None, and
> then is transformed into a compiler object. That's the bug.
> 
> If you call it again, it'll break because the new_compiler() function
> will receive self.compiler, which is supposed to be a string not a
> compiler object.

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.

> "compiler" is described as the "compiler type" in the options list of
> build_ext and should receive a string value.
> 
> So what's broken is the fact that third-party code is using "compiler" 
> as a compiler object attribute for years, because the command was
> creating the compiler object on the compiler option, rather than using
> its own attribute for that. And from an architectural point of view, if
> you have to tweak the compiler options by tweaking them direclty, it
> means that the build_ext command did a bad job with in the options
> it provides.

I agree that it's not exactly ideal to have an attribute first
be a string and then an object.

> For the cross-version incompatibility you are mentioning, it means that
> your code is working with "compiler" as a string option, then continue
> to work with it as a compiler object right after the command is run.

Not quite: extensions of build_ext will likely customize the
way the extension objects are built, ie. override .build_extensions()
which is called after .compiler has been set to the compiler instance.

So they always work with the compiler instance. And they don't really care
about the option at all, since all that information is available from
looking at the compiler object.

> But either way, there will be an incompatibility starting at 3.3 because
> we are going from the state "compiler is a string and also a compiler
> object, depending on when you use it" to "compiler is a only string option"
> 
> This is an inconsistent behavior I am fixing here. While the code may be
> more complex with the descriptor, this will eventually go away in 3.3
> (and 2.8 if it exists).
> 
> What is the other solution you where thinking about ? adding a
> compiler_type option and keep the compiler option woud introduce more
> incompatibilities since "compiler" is used to configure build_ext by
> many code out there, while tweaking the compiler object itself is an
> advanced usage done by less people, which may do the same thing in an
> easy way by using another attribute.

First of all, you only use a single compiler for building an
Python package, so using the global build compiler option will do
just fine (and is also required if you have other commands
rely on this information as well, such as the config command,
the build_clib command or other custom commands).

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.

Please note that it's common practice in distutils to have
the compiler instance in an .compiler attribute, so either
you change it in all cases or not at all.

The fact that the options on some of those commands is
named --compiler as well, is rather unfortunate.

Regarding wide-spread use of the compiler command line option:
I am only aware of the cygwin/mingw32 case where you'd really
need it. In all other cases I know, the default choice based
on the compiler with which Python itself was compiled will
work fine.