Message90439
> 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 ? |
|
Date |
User |
Action |
Args |
2009-07-12 07:32:35 | tarek | set | recipients:
+ tarek, lemburg, exarkun, atuining, benjamin.peterson, nicdumz, rpetrov |
2009-07-12 07:32:35 | tarek | set | messageid: <1247383955.03.0.80988036431.issue6377@psf.upfronthosting.co.za> |
2009-07-12 07:32:33 | tarek | link | issue6377 messages |
2009-07-12 07:32:32 | tarek | create | |
|