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 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

...

...

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.

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

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.

> > 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

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/)

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