Mark Hammond wrote:

Not sure what you mean here? I did find it strange that I could not setup the compiler as I would for any other project on the planet (ie, vie the env vars that the compiler itself supports), but that was pronounced to be a feature of distutils, so I dropped it.

Let's not drop it. When I asked about this feature years ago, I dropped it because people told me that real Windows users would never want this feature. Presumably that only reason I was asking was that I was a wayward Unix developer in Windows land. You, on the other hand, can make some claim to being a real Windows user. A patch to honor environment variables when they are set would help developers and, presumably, hurt no one. (No real Windows user would set an environment variable anyway.) Jeremy

In article , Thomas Heller writes .....

...

A patch to honor environment variables when they are set would help developers and, presumably, hurt no one. (No real Windows user would set an environment variable anyway.)

I'm not sure I'm in the position to pronounce on this, but: If someone comes up with a patch that does this, I have nothing against it. But I'm not prepared to support and/or debug configurations the users may have which are very different from my own.

this seems a bit harsh to me; I understand the part about being unable to debug, but surely this software is supposed to be a bit more robust. It is after all the product of more than one person and is now in the standard distro. Even M$ gives us VCVARS32.BAT so they presumably believe in that. I don't buy the argument about having to use the gui to set stuff up as distutils is a script/command line tool. I suppose we now face more difficult times with both MSC7/6 as the 'standard', but isn't that why distutils should consult the host python to determine which is preferable.

If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the enviroment vars itself - this is (one of?) the difficultiy I see.

Thomas

_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Robin Becker

Robin Becker writes:

In article , Thomas Heller writes .....

...

...

A patch to honor environment variables when they are set would help developers and, presumably, hurt no one. (No real Windows user would set an environment variable anyway.)

I'm not sure I'm in the position to pronounce on this, but: If someone comes up with a patch that does this, I have nothing against it. But I'm not prepared to support and/or debug configurations the users may have which are very different from my own.

this seems a bit harsh to me; I understand the part about being unable to debug, but surely this software is supposed to be a bit more robust.

Yes, it was too harsh, and I apologize for that. I was concerned about backwards compatibility and such.

It is after all the product of more than one person and is now in the standard distro. Even M$ gives us VCVARS32.BAT so they presumably believe in that. I don't buy the argument about having to use the gui to set stuff up as distutils is a script/command line tool.

Most probably a misunderstanding: Nobody needs to use the compiler gui or ide with distutils. *But the ide has to be started at least once* after installing MSVC 6 to create all the registry entries that distutils reads. It took quite some time to find this out, and I worked on quite a lot of bug reports to SF and on c.l.p for this. I don't know whether 7.x requires it or not.

I suppose we now face more difficult times with both MSC7/6 as the 'standard', but isn't that why distutils should consult the host python to determine which is preferable.

So, please someone submit a patch to let distutils use the environment. And apologies again, Thomas

"Mark Hammond" writes: [Thomas]

...

If I understand Mark correctly, the MSVC 7 GUI doesn't pick up the enviroment vars itself - this is (one of?) the difficultiy I see.

Nope, this isn't a problem. I have 2 specific problems:

* Manually setting LIB/INCLUDE has no effect, as distutils overwrites these values with what it thinks they should be * MSVC7 doesn't seem to store its paths in the registry.

MSVC7's GUI probably doesn't pick up the LIB/INCLUDE vars at startup time - but this is rarely an issue - the only time I expect to set or use these vars is when running from the command-line (which is exactly where distutils is run from :)

I think there is a simple fix to keep most people happy. distutils can just *append* the existing env var value to the new value. I think it is acceptable to say distutils wont let you set these to change the location of standard libraries or headers, but will let you add new ones.

So there's no need to read the entries set in MSVC7 itself (for which you have uploaded a patch) ? Thomas

"Mark Hammond" writes:

...

...

I think there is a simple fix to keep most people happy. distutils can just *append* the existing env var value to the new value. I think it is acceptable to say distutils wont let you set these to change the location of standard libraries or headers, but will let you add new ones.

So there's no need to read the entries set in MSVC7 itself (for which you have uploaded a patch) ?

:) Well, that would work I guess. I see no reason we can't support both the "GUI config" and "environment config", but if you felt it appropriate to support only the environment variables, it wouldn't really upset me.

I would find it strange if a naive setup script would use different include and lib directories depending on whether win32all is installed or not. IIRC, distutils need to read the registry was the reason that the _winreg module was added to the Python core. Maybe its time to add a distutils_util compiled extension for windows specific features (do I need a smiley here or not - not sure) ?

But I point out again that the way things stand at the moment, *neither* work with MSVC7.1

Mark.

Thomas

"Mark Hammond" writes:

...

I would find it strange if a naive setup script would use different include and lib directories depending on whether win32all is installed or not.

I agree.

...

IIRC, distutils need to read the registry was the reason that the _winreg module was added to the Python core.

Maybe its time to add a distutils_util compiled extension for windows specific features (do I need a smiley here or not - not sure) ?

I think that exposing SHGetSpecialFolderPath() would be a valuable addition to the Python runtime, and I guess that inside distutils would be a reasonable place for it.

It is already in wininst.exe, as you probably know, but unusable from the 'outside'. Same for code to create shortcuts, do you think that would be useful as well? Thomas

"Mark Hammond" writes:

...

It is already in wininst.exe, as you probably know, but unusable from the 'outside'. Same for code to create shortcuts, do you think that would be useful as well?

I think there would be a case for moving *all* "module functions into a single distutils extension module - this would simplify the installation executable, and also open possibilities for other similar utilities.

This could be a part of a new distutils package, required to build the installers. But the installers, at run-time, cannot depend on it. Thomas

In article <9bdd01c3e9d7$49dce680$0200a8c0@eden>, Mark Hammond writes ......

...

Always seemed a bit daft to do this implicitly from the IDE (eg when I set things up for stackless my ordinary stuff seems to see the wrong paths).

Not sure what you mean here? I did find it strange that I could not setup the compiler as I would for any other project on the planet (ie, vie the env vars that the compiler itself supports), but that was pronounced to be a feature of distutils, so I dropped it.

I just feel it strange as you do that the tool should rely on another tool to do setup. I regularly use distutils with several different python versions. I would be lucky to be able to set up a single set of include/lib dirs that would work for all. That's not to say that some base set might be useful, but that's what I thought the base environment vars were for.

...

There is special code in there about version >=7 though.

if self.__version >= 7: key = (r"%s\%0.1f\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Director ies" % (self.__root, self.__version)) else: key = (r"%s\6.0\Build System\Components\Platforms" r"\Win32 (%s)\Directories" % (self.__root, platform))

Yes, I did see that special code. My issue is that MSVC7.1 is not storing these paths in the registry at all.

Again I see nothing unusual in VCxxx storing most of a project setup in a more and more opaque form. I would be a bit surprised if it stores nothing globally though. I am speaking blindly as I don't have access to 7 yet. I would prefer the priorities to be 1) environment, 2) python version, 3) compiler/tool global.

If you combine these 2 facts together (can't use env vars, MSVC doesn't store in the registry), it currently seems *impossible* to get MSVC7 to use an alternative path under distutils. My patch tries to address this (even if it seems the wrong one to support to me <wink>)

Can anyone else at least confirm that changing the directories in MSVC7 does not write the new paths to the registry? The standard paths seem to be written there at installation time, but changing paths in DevStudio does not change these registry values.

Mark. ... -- Robin Becker