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
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 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
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
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
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.
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. 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:
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
"Jeremy Hylton" <jeremy@alum.mit.edu> writes:
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.
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.
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.)
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 .....
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 wrote:
In article <r7xcezfq.fsf@python.net>, Thomas Heller <theller@python.net> 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.
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)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
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:
In article <r7xcezfq.fsf@python.net>, Thomas Heller <theller@python.net> 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
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.
"Mark Hammond" <mhammond@skippinet.com.au> 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
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. 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 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
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. 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.
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
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. Mark.
"Mark Hammond" <mhammond@skippinet.com.au> 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
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.
Doh! Maybe the same module sourcecode could be built both as a stand-alone module, and also statically included in the installation exe. That way we can almost still keep it fun :) Mark.
In article <9bdd01c3e9d7$49dce680$0200a8c0@eden>, Mark Hammond <mhammond@skippinet.com.au> 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
participants (5)
-
Jeremy Hylton -
M.-A. Lemburg -
Mark Hammond -
Robin Becker -
Thomas Heller