[NumPy-Tickets] [NumPy] #2018: Bug in distutils: compiling on Windows fails if Python is installed in a path with spaces.

[NumPy Trac]

#2018: Bug in distutils: compiling on Windows fails if Python is installed in a
path with spaces.
--------------------+-------------------------------------------------------
 Reporter:  almar   |       Owner:  somebody   
     Type:  defect  |      Status:  new        
 Priority:  normal  |   Milestone:  Unscheduled
Component:  Other   |     Version:  1.6.1      
 Keywords:          |  
--------------------+-------------------------------------------------------
 I found a bug in numpy.distutils, which is causing problems with compiling
 Cython code on Windows. I have reproduced this on Python 2.6 and Python
 3.2 (32 bit). (I first thought this issue had to do with the normal
 distutils package: bugs.python.org/issue13765)

 The problem occurs with the native msvc compiler. Using gcc (MinGW) works
 fine.

 The problem is that the command to link the libraries does not put double
 quotes around paths that have spaces in them. Unfortunately, the path
 where I have Python installed has spaces in it ("c:/program
 files/python26"). Small example of part of a link command:

 /LIBPATH:C:\Program Files (x86)\python32\libs.

 Note that the include_dirs DO have double quotes around them.

 I traced the problem down to the custom CCompiler_spawn() function which
 replaces the distutils spawn function. If I understand correctly, the idea
 is to use numpy's quote_args() in gen_lib_options() to put quotes around
 given library dirs, and to not check for the need of quotes in spawn. It
 seems, however, as if one forgot that the libary dirs returned by
 _distutils_gen_lib_options() can also contain spaces. And they do if you
 install Python in "program files".

 Anyway, I propose to fix the problem by placing the following line at the
 very start of the CCompiler_spawn() function:
 cmd = quote_args(cmd)

 Additionally, I propose to change quote_args to also check whether the
 LAST character is a quote. This seems a bit more robust. Consider the two
 cases:
 /LIBPATH:"C:\Program Files (x86)\python32\libs"
 "/LIBPATH:C:\Program Files (x86)\python32\libs"



 ===== Below follows a minimal Cython example and traceback =====

 ===== test_.pyx
 def foo():
 print('hello')


 ===== setup.py
 import os, sys
 from Cython.Distutils import build_ext
 from distutils.core import setup
 from distutils.extension import Extension
 from numpy.distutils.misc_util import get_numpy_include_dirs

 # Ugly hack so I can run setup.py in my IDE
 sys.argv = ['setup.py', 'build_ext', '--inplace']

 # Init include dirs
 include_dirs = ['.']
 include_dirs.extend(get_numpy_include_dirs())

 # Creat Extensions
 ext_modules = [
      Extension('test_', ['test_.pyx'],
         include_dirs=include_dirs,
         ),
      ]

 # Compile
 setup(
     cmdclass = {'build_ext': build_ext},
     ext_modules = ext_modules,
     )

 print('Successfully compiled cython file: test_')


 ===== output when running setup.py
 running build_ext
 No module named msvccompiler in numpy.distutils; trying from distutils
 cythoning test_.pyx to test_.c
 building 'test_' extension
 C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c
 /nologo /Ox /MD /W3 /GS- /DNDEBUG -I. -I"C:\Program Files
 (x86)\python32\lib\site-packages\numpy\core\include" -I"C:\Program Files
 (x86)\python32\include" -I"C:\Program Files (x86)\python32\PC" /Tctest_.c
 /Fobuild\temp.win32-3.2\Release\test_.obj
 Found executable C:\Program Files (x86)\Microsoft Visual Studio
 9.0\VC\BIN\cl.exe
 C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\link.exe /DLL
 /nologo /INCREMENTAL:NO /LIBPATH:C:\Program Files (x86)\python32\libs
 /LIBPATH:C:\Program Files (x86)\python32\PCbuild /EXPORT:PyInit_test_
 build\temp.win32-3.2\Release\test_.obj
 /OUT:C:\almar\projects\py\cmu1394\test_.pyd
 /IMPLIB:build\temp.win32-3.2\Release\test_.lib
 /MANIFESTFILE:build\temp.win32-3.2\Release\test_.pyd.manifest
 Found executable C:\Program Files (x86)\Microsoft Visual Studio
 9.0\VC\BIN\link.exe
 LINK : fatal error LNK1181: cannot open input file 'Files.obj'

-- 
Ticket URL: <http://projects.scipy.org/numpy/ticket/2018>
NumPy <http://projects.scipy.org/numpy>
My example project