[issue6377] distutils compiler switch ignored

Steve Dower added the comment: Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils. If this issue does not relate to distutils, please remove the component and reopen it. If y

[issue6377] distutils compiler switch ignored

Changes by Jean-Paul Calderone : -- nosy: -exarkun ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue6377] distutils compiler switch ignored

Changes by Mark Lawrence : -- versions: +Python 3.4, Python 3.5 -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue6377] distutils compiler switch ignored

Changes by R. David Murray : -- nosy: +eric.araujo stage: -> unit test needed type: -> behavior ___ Python tracker ___ ___ Python-bug

[issue6377] distutils compiler switch ignored

Changes by Craig McQueen : -- nosy: +cmcqueen1975 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue6377] distutils compiler switch ignored

Changes by Tarek Ziadé : -- nosy: +dalcinl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue6377] distutils compiler switch ignored

Changes by Tarek Ziadé : -- priority: -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue6377] distutils compiler switch ignored

Tarek Ziadé 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 some

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: 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

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: > 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. In practice yes that's true. > The "compiler" option on the build_ext an

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: @Nicolas : That's because you run it with Python 2.6 distutils, which doesn't have that change. If you want to build the current trunk with Python 2.6, you may want to install a standalone version of distutils. I have a nightly build of the trunk you may install i

[issue6377] distutils compiler switch ignored

Nicolas Dumazet added the comment: It seems that the fix is still not perfect. At the moment ( r73906 ), if you try to build trunk using Python 2.6, you get: > python setup.py build running build running build_ext Traceback (most recent call last): File "setup.py", line 1901, in main()

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: FWIW: I've changed our mxSetup code to use a method for accessing the compiler instance. Perhaps that's the better way to go for standard distutils commands as well ?! E.g. .get_compiler_object() -- ___ Python t

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: > Tarek Ziadé 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 t

[issue6377] distutils compiler switch ignored

Tarek Ziadé 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()

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Tarek Ziadé wrote: > Tarek Ziadé added the comment: > > I'll set back the compiler attribute when compiler_obj is set too, > so third-party code will be able to work with it as before. > > The current code will deprecate this usage, by displaying a depre

[issue6377] distutils compiler switch ignored

Jean-Paul Calderone added the comment: Cool, thanks. PyCrypto also works again now. -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: done in r73895, r73896. (and tested with twisted trunk). -- ___ Python tracker ___ ___ Python-bugs-list

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: I'll set back the compiler attribute when compiler_obj is set too, so third-party code will be able to work with it as before. The current code will deprecate this usage, by displaying a deprecation warning: - if the compiler is set to anything else than a strin

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Roumen Petrov wrote: > Roumen Petrov added the comment: > > Trunk may be is not affected. I successfully cross-compile with GNU > compiler for windows (see issue 3871). It is affected in the sense that .compile was changed to .compile_obj and that change

[issue6377] distutils compiler switch ignored

Roumen Petrov added the comment: Trunk may be is not affected. I successfully cross-compile with GNU compiler for windows (see issue 3871). -- nosy: +rpetrov ___ Python tracker _

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Marc-Andre Lemburg wrote: > Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be > removed or renamed to .compiler_obj. There's a lot of bdist_ext > distutils code out there relying on having the .compiler object available. Sorry, the ab

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Added Python 2.7 since it fails there as well. -- versions: +Python 2.7 ___ Python tracker ___ _

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Note that the config command also uses a .compiler instance for actually doing work, rather than as command option. -- ___ Python tracker __

[issue6377] distutils compiler switch ignored

Marc-Andre Lemburg added the comment: Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be removed or renamed to .compiler_obj. There's a lot of bdist_ext distutils code out there relying on having the .compiler object available. A much better fix would be to map the option

[issue6377] distutils compiler switch ignored

Jean-Paul Calderone added the comment: It looks like this change may have broken some parts of distutils. For example, Twisted's setup.py now produces this output when running the build_ext command: $ ~/Projects/python/trunk/python setup.py build_ext running build_ext Traceback (most recent ca

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: merged in r73866 in py3k Thanks for the feedback -- status: open -> closed ___ Python tracker ___ ___

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: done in r73864, waiting for the buildbots to build trunk, then will be applied in 3.x -- ___ Python tracker ___ ___

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: Right, turning compiler into a property and adding a warning on the set would be good enough I guess. Then turn it back into a simple string for python 3.3 and ... 2.8 :) I'll add that -- ___ Python tracker

[issue6377] distutils compiler switch ignored

Benjamin Peterson added the comment: I think the patch is fine. (Did you try using the descriptor protocol to add a deprecation warning?) -- ___ Python tracker ___ __

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: Here's the patch. There's no simple way to deprecate the usage of "compiler" as an attribute, so I have just fixed Python setup.py. Using it as an attribute is just wrong. I have put Benjamin in the loop and I'll wait for his greenlight to commit this change. ---

[issue6377] distutils compiler switch ignored

Tarek Ziadé added the comment: yes, the problem is that this option (string) is also used as an attribute (compiler object). But Python itself uses as an attribute.. I have to check its type at this spot, and deprecate the usage of "compiler" as an attribute. -- resolution: -> accept

[issue6377] distutils compiler switch ignored

New submission from Anthony Tuininga : With the release of Python 3.1 the --compiler switch is ignored in Lib/distutils/command/build_ext.py. The attached patch fixes that issue. Once that was fixed there was another issue with get_version() in cygwincompiler but that appears to be fixed in the 3