[issue39917] new_compiler() called 2nd time causes error

[Todd Levi]

Todd Levi  added the comment:

In looking through the setup.py file for uvloop, I see that they purposely do 
not call super().initialize_options() or super().finalize_options() in their 
code if they've already been called once.

I think that is why their code is revealing this problem - the 2nd command to 
be run is inheriting the self.compiler value from the first command since 
build_ext.initialize_options() isn't being called to (re)set self.compiler to 
be None.

I'm not sure if there's a "rule" that says each command must call 
initialize_options() to "sanitize" the object or not but that does explain why 
the 2nd command is seeing a CCompiler object() for self.compiler on the 2nd 
time through.

--

___
Python tracker 
<https://bugs.python.org/issue39917>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39917] new_compiler() called 2nd time causes error

[Todd Levi]

New submission from Todd Levi :

Action:
Run the following command in py36, py37, and py3 for package uvloop

python setup.py build_ext --inline bdist_wheel

Expected behavior:

The package is built and bundled as a wheel.

Observed behavior:

The build fails at the bdist_wheel stage with the following error:

error: don't know how to compile C/C++ code on platform 'posix' with 
'' compiler

Additional Notes:

If I split the two commands (build_ext and bdist_wheel) into separate 
invocations (e.g. python setup.py build_ext --inline && python setup.py 
bdist_wheel) then the wheel is successfully built.  It only (and always) fails 
when build_ext and bdist_wheel are on the same command line.

What "seems" to be happening is that bdist_wheel is somehow inheriting the 
existing CCompiler object that was used by build_ext and is then passing that 
back to distutils.compiler.new_compiler().  The new_compiler() function simply 
checks to see if compiler is None and, if not, uses its value as a key to the 
compiler_class dict.

The distutils/command/build_ext build_ext object initially sets self.compiler 
to None so the first invocation of new_compiler() in build_ext.run() will work 
as expected.  In build_ext.run() at around line 306 (in master), however, it 
simply does self.compiler = new_compiler(compiler=self.compiler,...) so any 
subsequent invocation of run() seems like it will fail and produce the error 
message I'm seeing.  new_compiler() is the only place I see that error message 
being emitted.

The package I'm building (uvloop) is being built with Cython but all the object 
paths I've been able to track come back to distutils.ccompiler.py.  That 
packages setup.py file doesn't seem to do anything weird that I can see (which 
doesn't mean it isn't doing something weird).  It sets the sdist and build_ext 
cmdclass entries to their own methods (that don't seem to set compiler - just 
compiler options) and also registers an extension via ext_modules.  The 
setup.py code is here: https://github.com/MagicStack/uvloop/blob/master/setup.py

Possible Fix:

Two simple possibilities come to mind.  1) In run, see if self.compiler is not 
None and alter the call to new_compiler() to use self.compiler.compiler_type.  
2) In new_compiler(), check the type of compiler and simply return if its a 
CCompiler object.

--
components: Distutils
messages: 363765
nosy: dstufft, eric.araujo, televi
priority: normal
severity: normal
status: open
title: new_compiler() called 2nd time causes error
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue39917>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com