Hello all, I'm brand new to distutils, but wanted to install the newest numpy on my WinNT machine to try out some recent array-casting enhancements. Downloading distutils-20000117.tar.gz and installing with "python setup.py install" seemed to go fine. Then I downloaded Numerical-15.2.tar.gz from sourceforge and got the following ... C:\temp\Numerical-15.2> python setup.py build install running build running build_py not copying Lib\ArrayPrinter.py (output up-to-date) <=== 2nd run of above, not copying Lib\FFT.py (output up-to-date) <=== 1st run did copy not copying Lib\LinearAlgebra.py (output up-to-date) not copying Lib\MLab.py (output up-to-date) not copying Lib\Matrix.py (output up-to-date) not copying Lib\Numeric.py (output up-to-date) not copying Lib\Precision.py (output up-to-date) not copying Lib\RandomArray.py (output up-to-date) not copying Lib\UserArray.py (output up-to-date) running build_ext cl.exe /nologo /Ox /MD -Id:\program files\python\include\python1.5 -Id:\program files\python\include -IInclude /c /FoSrc/_numpymodule.obj /TcSrc/_numpymodule.c Traceback (innermost last): File "setup.py", line 58, in ? ext_modules = [('_numpy', File "d:\program files\python\distutils\core.py", line 96, in setup dist.run_commands () File "d:\program files\python\distutils\core.py", line 442, in run_commands self.run_command (cmd) File "d:\program files\python\distutils\core.py", line 491, in run_command cmd_obj.run () File "d:\program files\python\distutils\command\build.py", line 52, in run self.run_peer ('build_ext') File "d:\program files\python\distutils\core.py", line 802, in run_peer self.distribution.run_command (command) File "d:\program files\python\distutils\core.py", line 491, in run_command cmd_obj.run () File "d:\program files\python\distutils\command\build_ext.py", line 146, in run self.build_extensions (self.extensions) File "d:\program files\python\distutils\command\build_ext.py", line 209, in build_extensions include_dirs=include_dirs) File "D:\Program Files\Python\distutils\msvccompiler.py", line 103, in compile self.spawn ([self.cc] + cc_args) File "D:\Program Files\Python\distutils\ccompiler.py", line 431, in spawn spawn (cmd, verbose=self.verbose, dry_run=self.dry_run) File "D:\Program Files\Python\distutils\spawn.py", line 37, in spawn _spawn_nt (cmd, search_path, verbose, dry_run) File "D:\Program Files\Python\distutils\spawn.py", line 70, in _spawn_nt raise DistutilsExecError, \ distutils.errors.DistutilsExecError: command 'cl.exe' failed: No such file or directory C:\temp\Numerical-15.2> Is this a known problem? In the distutils test/ directory, I was able to successfully run every program except test_fgo.py and test_getopt.py (which gave ImportErrors on distutils.exceptions) and test_spawn.py (which crashed when looking for /bin/ls). Any assistance would be most gratefully accepted (please copy any replies to my email address). Gary
[...]
running build_ext cl.exe /nologo /Ox /MD -Id:\program files\python\include\python1.5 -Id:\program files\python\include -IInclude /c /FoSrc/_numpymodule.obj /TcSrc/_numpymodule.c Traceback (innermost last): File "setup.py", line 58, in ? ext_modules = [('_numpy', File "d:\program files\python\distutils\core.py", line 96, in setup dist.run_commands () File "d:\program files\python\distutils\core.py", line 442, in run_commands self.run_command (cmd) File "d:\program files\python\distutils\core.py", line 491, in run_command cmd_obj.run () File "d:\program files\python\distutils\command\build.py", line 52, in run self.run_peer ('build_ext') File "d:\program files\python\distutils\core.py", line 802, in run_peer self.distribution.run_command (command) File "d:\program files\python\distutils\core.py", line 491, in run_command cmd_obj.run () File "d:\program files\python\distutils\command\build_ext.py", line 146, in run self.build_extensions (self.extensions) File "d:\program files\python\distutils\command\build_ext.py", line 209, in build_extensions include_dirs=include_dirs) File "D:\Program Files\Python\distutils\msvccompiler.py", line 103, in compile self.spawn ([self.cc] + cc_args) File "D:\Program Files\Python\distutils\ccompiler.py", line 431, in spawn spawn (cmd, verbose=self.verbose, dry_run=self.dry_run) File "D:\Program Files\Python\distutils\spawn.py", line 37, in spawn _spawn_nt (cmd, search_path, verbose, dry_run) File "D:\Program Files\Python\distutils\spawn.py", line 70, in _spawn_nt raise DistutilsExecError, \ distutils.errors.DistutilsExecError: command 'cl.exe' failed: No such file or directory C:\temp\Numerical-15.2>
Is this a known problem? In the distutils test/ directory, I was able to successfully run every program except test_fgo.py and test_getopt.py (which gave ImportErrors on distutils.exceptions) and test_spawn.py (which crashed when looking for /bin/ls).
You have to make sure that the environment is set up for VC. Run the file vcvars32.bat in the Visual C bin directory. Thomas Heller
Thomas Heller wrote:
[...]
running build_ext [errors running MSVC]
You have to make sure that the environment is set up for VC. Run the file vcvars32.bat in the Visual C bin directory.
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
In article <388D6121.A4D31685@lemburg.com>, M.-A. Lemburg <mal@lemburg.com> writes
Thomas Heller wrote:
[...]
running build_ext [errors running MSVC]
You have to make sure that the environment is set up for VC. Run the file vcvars32.bat in the Visual C bin directory.
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places. Then it can just issue the correct commands with the path attached or tell the user it can't find cl.exe/link.exe and then ask for vcvars32.bat to be run first. I assume we're not going to search all known drives for the correct exe's. I guess we're not allowed to look in the registry unless Mark Hammond's things are around. -- Robin Becker
In article <388D6121.A4D31685@lemburg.com>, M.-A. Lemburg <mal@lemburg.com> writes
Thomas Heller wrote:
[...]
running build_ext [errors running MSVC]
You have to make sure that the environment is set up for VC. Run the
file
vcvars32.bat in the Visual C bin directory.
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places. Then it can just issue the correct commands with the path attached or tell the user it can't find cl.exe/link.exe and then ask for vcvars32.bat to be run first. I assume we're not going to search all known drives for the correct exe's.
I guess we're not allowed to look in the registry unless Mark Hammond's things are around. -- Python should *really* have a standard module allowing (at least) to read the registry.
Thomas Heller
On 25 January 2000, Robin Becker said:
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
I'll happily accept patches! (I'd prefer not to be the one to translate a Microsoft-written batch file into Python: there're reasons I abandoned DOS almost 6 years ago, and batch files were one of them...)
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places.
Depends what you mean by "well-known places". If you mean os.environ['PATH'], then the spawn module can (and should) do a bit of work ahead of time to see if the expected command is really there. Also, somebody somewhere should probably catch that exception and die without a traceback. Not sure whose responsibility that is; I guess it belongs in the compiler class (MSVCCompiler in this case). If you mean encoding some knowledge about where MSVC++ is "typically" installed, then that might belong in the MSVCCompiler class. I'll need a good explanation and broad consensus from the Windows experts in the crowd before I'll put that kind of code in, though. As for dreaming about searching the registry: as long as it's not available under Python 1.5.*, then I don't want Distutils to depend on it. Greg
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
I'll happily accept patches! (I'd prefer not to be the one to translate a Microsoft-written batch file into Python: there're reasons I abandoned DOS almost 6 years ago, and batch files were one of them...)
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places.
Depends what you mean by "well-known places". If you mean os.environ['PATH'], then the spawn module can (and should) do a bit of work ahead of time to see if the expected command is really there.
As for dreaming about searching the registry: as long as it's not available under Python 1.5.*, then I don't want Distutils to depend on it. The conclusion is: You can not do too much under NT when you cannot look into the registry. (That reminds me of the 'good old times' when every program added its own
On NT, there are three kinds of "well-known places": 1. on the PATH 2. in the default directory which MS suggests when installing MSVC 3. in the real directory where MSVC is installed, assumuming the default has not been accepted. Only 1 is easy. Points 2 and 3 can only be retrieved by searching the registry, because even the default directory depends on the Windows Version: (english) c:\Program Files\... (german) c:\Programme\... Note that not only you have to know where to find cl.exe, you also have to set the INCLUDE and LIB directories! We could assume that a developer who has installed MSVC would know how to set up the environment, but I guess this is usually not the case, because most developers I know of simply fire up DevStudio, they never use the command line. directory to the PATH ;-)
Greg
Thomas Heller
Greg Ward wrote:
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
I'll happily accept patches! (I'd prefer not to be the one to translate a Microsoft-written batch file into Python: there're reasons I abandoned DOS almost 6 years ago, and batch files were one of them...)
What I had in mind was that distutils should execute vcvars32.bat prior to calling calling the compiler. Should be simple enough, I guess, although I'm not sure how you have implemented OS environment inheritance... could be that you have to execute vcvars32.bat prior to *every* call to MSVC. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Greg Ward wrote:
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
I'll happily accept patches! (I'd prefer not to be the one to translate a Microsoft-written batch file into Python: there're reasons I abandoned DOS almost 6 years ago, and batch files were one of them...)
What I had in mind was that distutils should execute vcvars32.bat prior to calling calling the compiler. Should be simple enough, I guess, although I'm not sure how you have implemented OS environment inheritance... could be that you have to execute vcvars32.bat prior to *every* call to MSVC.
Does not work, because you do not know where to find it. It is *not* on the path, it is in the VC/bin directory. Maybe even that it is optional (I do not remember). Thomas Heller
Thomas Heller wrote:
Greg Ward wrote:
Perhaps the msvccompiler.py class should take care of this too... it would sure help to avoid a distutils FAQ.
I'll happily accept patches! (I'd prefer not to be the one to translate a Microsoft-written batch file into Python: there're reasons I abandoned DOS almost 6 years ago, and batch files were one of them...)
What I had in mind was that distutils should execute vcvars32.bat prior to calling calling the compiler. Should be simple enough, I guess, although I'm not sure how you have implemented OS environment inheritance... could be that you have to execute vcvars32.bat prior to *every* call to MSVC.
Does not work, because you do not know where to find it. It is *not* on the path, it is in the VC/bin directory. Maybe even that it is optional (I do not remember).
I have that directory on my PATH... I don't remember whether I put it there or the MSVC installation did, though. Even if it cannot be found: trying to run vcvars32.bat prior to executing cl.exe should be ok in any case... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places. Then it can just issue the correct commands with the path attached or tell the user it can't find cl.exe/link.exe and then ask for vcvars32.bat to be run first. I assume we're not going to search all known drives for the correct exe's.
I agree. IMO, we could take the following approach: * Look in C:\Program Files\The default place\... * Look in \Program Files\The default place\... * Try and import win32api, catching the import error And if that fails, give the user a nice polite message. This is likely to catch 95% of the cases, and still make it obvious what the user should do in the small percentage left... However, it is worth noting that running "vcvars32.bat" wont work if run via a seperate "system()" call - the environment variables set will not persist. The only decent solution I can see is to create a temporary batch file, that first calls "vcvars32.bat" before the builds. Depending on how distutils does its thing, it may just be simpler to detect the condition, and politely ask the user to run the batch file themselves... Mark.
On 31 January 2000, Mark Hammond said:
Surely msvccompiler can tell if a particular file (say cl.exe) isn't in any of the well known places. Then it can just issue the correct commands with the path attached or tell the user it can't find cl.exe/link.exe and then ask for vcvars32.bat to be run first. I assume we're not going to search all known drives for the correct exe's.
I agree. IMO, we could take the following approach: * Look in C:\Program Files\The default place\... * Look in \Program Files\The default place\... * Try and import win32api, catching the import error
Two things: * what is "The default place"? * if/when a standard Python 1.6 way for accessing the Windows registry comes into existence, should it be added that to list? Otherwise, that sounds good. Patches welcome, tested patches especially so.
However, it is worth noting that running "vcvars32.bat" wont work if run via a seperate "system()" call - the environment variables set will not persist. The only decent solution I can see is to create a temporary batch file, that first calls "vcvars32.bat" before the builds. Depending on how distutils does its thing, it may just be simpler to detect the condition, and politely ask the user to run the batch file themselves...
Yecch. 1) I don't like the idea of running a batch file (or shell script on the Unix side) for every compiler invocation -- I haven't worried much about performance on the Python side so far in the Distutils (since copying and compiling files is so expensive), but I might have to draw the line at this. 2) If I have no idea where cl.exe is, how am I supposed to know where vcvars32.bat is? Greg
> > I agree. IMO, we could take the following approach: > > * Look in C:\Program Files\The default place\... > > * Look in \Program Files\The default place\... > > * Try and import win32api, catching the import error > > Two things: > * what is "The default place"? IMHO there is no default place (tm), because even "c:\Program Files\" is only correct under certain circmustances: For a german version of NT, it is "c:\Programme", if NT is installed on another drive,it may be D:\Programme, and so on. On the other hand, if we really have to guess, it is the best guess we can make. > * if/when a standard Python 1.6 way for accessing the Windows registry > comes into existence, should it be added that to list? I think distutils is a good reason why we need it. I'm currently working on a module which hopefully will be included. > > However, it is worth noting that running "vcvars32.bat" wont work if run via > > a seperate "system()" call - the environment variables set will not persist. > > The only decent solution I can see is to create a temporary batch file, that > > first calls "vcvars32.bat" before the builds. Depending on how distutils > > does its thing, it may just be simpler to detect the condition, and politely > > ask the user to run the batch file themselves... > > Yecch. 1) I don't like the idea of running a batch file (or shell > script on the Unix side) for every compiler invocation -- I haven't > worried much about performance on the Python side so far in the > Distutils (since copying and compiling files is so expensive), but I > might have to draw the line at this. I second that. 2) If I have no idea where cl.exe > is, how am I supposed to know where vcvars32.bat is? Exactly. Note that vcvars32.bat does more than extend the PATH to include the directory where cl.exe resides, it also sets INCLUDE and LIB environment vars (which we can also supply on the command line). Thomas Heller
I propose the following: 1. Convince Guido to give python 1.6 registry access in the core. I'm currently working on such a module. 2. (>=1.6) Use the registry to find Path, Include, and Lib directories for VC, and supply them on the command line. 3. (<1.6) Try to import win32api and win32con, and use Robins code to find the directories. If this also fails, inform the user that the environment must be set up for VC by running vcvars32.bat, and restarting setup.py. Note that it also may be possible the VC is not installed at all! I think we should come to a conclusion here, and offer Greg some tested patches. I'm willing to work on this. Thomas Heller
1. Convince Guido to give python 1.6 registry access in the core. I'm currently working on such a module.
Sure. Mail it to me ASAP. You'll also have to snail-mail me a wet signature on the conbtribution release form: http://www.python.org/1.5/wetsign.html. (I apologize for this sillyness, our lawyers require it and who am I to argue with them...)
2. (>=1.6) Use the registry to find Path, Include, and Lib directories for VC, and supply them on the command line.
3. (<1.6) Try to import win32api and win32con, and use Robins code to find the directories. If this also fails, inform the user that the environment must be set up for VC by running vcvars32.bat, and restarting setup.py. Note that it also may be possible the VC is not installed at all!
Or the wrong version. --Guido van Rossum (home page: http://www.python.org/~guido/)
1. Convince Guido to give python 1.6 registry access in the core. I'm currently working on such a module.
Sure. Mail it to me ASAP. You'll also have to snail-mail me a wet signature on the conbtribution release form: http://www.python.org/1.5/wetsign.html. (I apologize for this sillyness, our lawyers require it and who am I to argue with them...)
How much time do we have to make this ready for 1.6? Hours, days, weeks? Thomas Heller
On 01 February 2000, Thomas Heller said:
I propose the following:
1. Convince Guido to give python 1.6 registry access in the core. I'm currently working on such a module.
2. (>=1.6) Use the registry to find Path, Include, and Lib directories for VC, and supply them on the command line.
3. (<1.6) Try to import win32api and win32con, and use Robins code to find the directories. If this also fails, inform the user that the environment must be set up for VC by running vcvars32.bat, and restarting setup.py. Note that it also may be possible the VC is not installed at all!
That sounds like a good plan.
I think we should come to a conclusion here, and offer Greg some tested patches. I'm willing to work on this.
Excellent! Probably a good place to start is with Robin's latest patch, which looks like it fulfills #3 on your list. Try applying that to 0.1.3 and see if it works for you as well as it did for Robin. Let us know how it goes. Thanks! Greg
participants (7)
-
Gary Strangman -
Greg Ward -
Guido van Rossum -
M.-A. Lemburg -
Mark Hammond -
Robin Becker -
Thomas Heller