MSVC7 directories

Just incase it slips under the radar, I have opened a bug regarding MSVC7 directories. Specifically, changes I make to the directories in the MSVC7 GUI are not seen by distutils. All the details, and a patch, is in the bug: http://www.python.org/sf/883969 [ 883969 ] distutils doesn't see user-directories set via VisStudio 7.1 Any comments appreciated, Thanks, Mark

In article <075401c3e39c$34d84d60$2c00a8c0@eden>, Mark Hammond <mhammond@skippinet.com.au> writes paths). 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)) -- Robin Becker

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.
Yes, I did see that special code. My issue is that MSVC7.1 is not storing these paths in the registry at all. 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.

Mark Hammond wrote:
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

"Jeremy Hylton" <jeremy@alum.mit.edu> writes:
Mark Hammond wrote:
IIRC, you asked for this feature because you had a misconfigured VC 6 installation - probably because you never ran the gui after installing the compiler.
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. 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

In article <r7xcezfq.fsf@python.net>, Thomas Heller <theller@python.net> writes .....
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.
-- Robin Becker

Robin Becker wrote:
I'm not sure I can follow you guys here: distutils is a command line tools, so why should we worry about the GUI of the compiler ? Indeed, the freely available C++ compiler in the .NET SDK should be enough to get distutils working with C extensions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 2004)
2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Robin Becker <robin@jessikat.fsnet.co.uk> writes:
Yes, it was too harsh, and I apologize for that. I was concerned about backwards compatibility and such.
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.
So, please someone submit a patch to let distutils use the environment. And apologies again, 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. Mark.

:) 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. But I point out again that the way things stand at the moment, *neither* work with MSVC7.1 Mark.

"Mark Hammond" <mhammond@skippinet.com.au> 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. 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) ?
Thomas

In article <9bdd01c3e9d7$49dce680$0200a8c0@eden>, Mark Hammond <mhammond@skippinet.com.au> writes ......
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.
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.

In article <075401c3e39c$34d84d60$2c00a8c0@eden>, Mark Hammond <mhammond@skippinet.com.au> writes paths). 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)) -- Robin Becker

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.
Yes, I did see that special code. My issue is that MSVC7.1 is not storing these paths in the registry at all. 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.

Mark Hammond wrote:
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

"Jeremy Hylton" <jeremy@alum.mit.edu> writes:
Mark Hammond wrote:
IIRC, you asked for this feature because you had a misconfigured VC 6 installation - probably because you never ran the gui after installing the compiler.
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. 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

In article <r7xcezfq.fsf@python.net>, Thomas Heller <theller@python.net> writes .....
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.
-- Robin Becker

Robin Becker wrote:
I'm not sure I can follow you guys here: distutils is a command line tools, so why should we worry about the GUI of the compiler ? Indeed, the freely available C++ compiler in the .NET SDK should be enough to get distutils working with C extensions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 04 2004)
2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Robin Becker <robin@jessikat.fsnet.co.uk> writes:
Yes, it was too harsh, and I apologize for that. I was concerned about backwards compatibility and such.
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.
So, please someone submit a patch to let distutils use the environment. And apologies again, 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. Mark.

:) 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. But I point out again that the way things stand at the moment, *neither* work with MSVC7.1 Mark.

"Mark Hammond" <mhammond@skippinet.com.au> 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. 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) ?
Thomas

In article <9bdd01c3e9d7$49dce680$0200a8c0@eden>, Mark Hammond <mhammond@skippinet.com.au> writes ......
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.
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.
participants (5)
-
Jeremy Hylton
-
M.-A. Lemburg
-
Mark Hammond
-
Robin Becker
-
Thomas Heller