New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
distutils compiler switch ignored #50626
Comments
With the release of Python 3.1 the --compiler switch is ignored in |
yes, the problem is that this option (string) is also used as an But Python itself uses as an attribute.. I have to check its type at this spot, and deprecate the usage of |
Here's the patch. There's no simple way to deprecate the usage of I have put Benjamin in the loop and I'll wait for his greenlight to |
I think the patch is fine. (Did you try using the descriptor protocol to |
Right, turning compiler into a property and adding a warning on the set I'll add that |
done in r73864, waiting for the buildbots to build trunk, then will be |
merged in r73866 in py3k Thanks for the feedback |
It looks like this change may have broken some parts of distutils. For $ ~/Projects/python/trunk/python setup.py build_ext
running build_ext
Traceback (most recent call last):
File "setup.py", line 97, in <module>
main(sys.argv[1:])
File "setup.py", line 92, in main
setup(**setup_args)
File "./twisted/python/dist.py", line 47, in setup
return core.setup(**get_setup_args(**kw))
File "/home/exarkun/Projects/python/trunk/Lib/distutils/core.py", line
149, in setup
dist.run_commands()
File "/home/exarkun/Projects/python/trunk/Lib/distutils/dist.py", line
926, in run_commands
self.run_command(cmd)
File "/home/exarkun/Projects/python/trunk/Lib/distutils/dist.py", line
945, in run_command
cmd_obj.run()
File
"/home/exarkun/Projects/python/trunk/Lib/distutils/command/build_ext.py", line
380, in run
self.build_extensions()
File "./twisted/python/dist.py", line 327, in build_extensions
self.prepare_extensions()
File "./twisted/python/dist.py", line 318, in prepare_extensions
if x.condition(self)]
File "twisted/runner/topfiles/setup.py", line 14, in <lambda>
condition=lambda builder: builder._check_header("rpc/rpc.h")),
File "./twisted/python/dist.py", line 359, in _check_header
self.compiler.announce("checking for %s ..." % header_name, 0)
AttributeError: 'NoneType' object has no attribute 'announce' And PyCrypto produces this output: running build_ext
Traceback (most recent call last):
File "setup.py", line 163, in <module>
core.setup(**kw)
File "/tmp/python-buildbot/local/lib/python2.7/distutils/core.py",
line 149, in setup
dist.run_commands()
File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 926, in run_commands
self.run_command(cmd)
File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
cmd_obj.run()
File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/install.py",
line 580, in run
self.run_command('build')
File "/tmp/python-buildbot/local/lib/python2.7/distutils/cmd.py", line
326, in run_command
self.distribution.run_command(command)
File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
cmd_obj.run()
File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/build.py",
line 132, in run
self.run_command(cmd_name)
File "/tmp/python-buildbot/local/lib/python2.7/distutils/cmd.py", line
326, in run_command
self.distribution.run_command(command)
File "/tmp/python-buildbot/local/lib/python2.7/distutils/dist.py",
line 945, in run_command
cmd_obj.run()
File
"/tmp/python-buildbot/local/lib/python2.7/distutils/command/build_ext.py",
line 380, in run
self.build_extensions()
File "setup.py", line 115, in build_extensions
self.detect_modules()
File "setup.py", line 119, in detect_modules
lib_dirs = self.compiler.library_dirs + ['/lib', '/usr/lib']
AttributeError: 'NoneType' object has no attribute 'library_dirs' |
Tarek, the .compiler attribute is needed by bdist_ext, so cannot just be A much better fix would be to map the option to a new attribute in In general, when making such changes, please test these against a few Thanks. |
Note that the config command also uses a .compiler instance for actually |
Added Python 2.7 since it fails there as well. |
Marc-Andre Lemburg wrote:
Sorry, the above should have read build_ext, not bdist_ext...
|
Trunk may be is not affected. I successfully cross-compile with GNU |
Roumen Petrov wrote:
It is affected in the sense that .compile was changed |
I'll set back the compiler attribute when compiler_obj is set too, The current code will deprecate this usage, by displaying a deprecation
so we can keep "compiler" as its initial purpose. And I'll test it on twisted and egenix. Thanks for the feedback |
done in r73895, r73896. (and tested with twisted trunk). |
Cool, thanks. PyCrypto also works again now. |
Tarek Ziadé wrote:
Could you please elaborate a bit on the reasoning behind The code did work before, so I'm not sure why you are trying With the change you:
Wouldn't it be better to either leave things are they have |
The build_ext command cannot be run twice, because the first time, the If you call it again, it'll break because the new_compiler() function "compiler" is described as the "compiler type" in the options list of So what's broken is the fact that third-party code is using "compiler" For the cross-version incompatibility you are mentioning, it means that This is an inconsistent behavior I am fixing here. While the code may be What is the other solution you where thinking about ? adding a |
Tarek Ziadé wrote:
You never run a command twice unless you explicitly reinitialize it
I agree that it's not exactly ideal to have an attribute first
Not quite: extensions of build_ext will likely customize the So they always work with the compiler instance. And they don't really care
First of all, you only use a single compiler for building an The "compiler" option on the build_ext and config commands Furthermore, the .finalize_options() methods could detect whether Please note that it's common practice in distutils to have The fact that the options on some of those commands is Regarding wide-spread use of the compiler command line option: |
FWIW: I've changed our mxSetup code to use a method for accessing Perhaps that's the better way to go for standard distutils commands |
It seems that the fix is still not perfect. At the moment ( r73906 ), if you try to build trunk using Python 2.6, > python setup.py build
running build
running build_ext
Traceback (most recent call last):
File "setup.py", line 1901, in <module>
main()
File "setup.py", line 1896, in main
'Lib/smtpd.py']
File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/distutils/command/build_ext.py", line 345, in run
self.build_extensions()
File "setup.py", line 103, in build_extensions
missing = self.detect_modules()
File "setup.py", line 302, in detect_modules
add_dir_to_list(self.compiler_obj.library_dirs, '/usr/local/lib')
File "/usr/lib/python2.6/distutils/cmd.py", line 112, in __getattr__
raise AttributeError, attr
AttributeError: compiler_obj |
@nicolas : That's because you run it with Python 2.6 distutils, which If you want to build the current trunk with Python 2.6, you may want to By the time 2.7 comes out, I'll probably publish an official standalone |
In practice yes that's true.
Having a single location sounds like the best idea with the current Now the question is, in practice, could someone force a I don't see a use case in practice for that, but if so, we would need to |
Tarek Ziadé wrote:
It is generally a bad idea to mix compiler types when compiling In practice, I don't think that any extension package will use However, it is well possible that a package may use differently In fact, a single command object may even use multiple compiler I think a workable solution to the problem with the compiler The build.get_compiler_object() could then return an instance The various .finalize_options() method would need to propagate You'd still have the situation that .compiler is used as |
The problem I see is that sometimes, people are using the build_ext $ python setup.py build_ext -i --compiler mingw32 So that means build_ext is not a subcommand of build in this case. But the code will have to be careful and not use the cache with this What about making it all simpler, by creating a base command class that That would resolve the code duplication and will make it simpler each This base command would have one single option. e.g. "compiler"
I am not sure to understand how .compiler will become a string |
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 you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: