This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author djohnanderson
Recipients
Date 2002-10-08.15:51:33
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=618290

Thanks Martin for taking the time to review my proposed changes.

I think your comments about looking in
Software\Microsoft\VisualStudio instead of
Software\Microsoft\DevStudio is a good point. I decided to
two look only in VisualStudio because that works for both
the version 6 and 7 compiler I tested with. I don't know if
the version 5 compiler also stores the version in DevStudio.
Another alternative, which would of course complicate code,
would be two look in both places and choose the highest
version. Let me know if that's what you'd prefer and I'll
upload a new patch.

The problem I'm having with the version 6 compiler (latest
service Pack 5) is that
SOFTWARE\Microsoft\Devstudio\6.0\Build System\ doesn't
exist. Instead it looks like it's been moved to
SOFTWARE\Microsoft\Shared Tools\Build System\, but in that
new location, SOFTWARE\Microsoft\Shared Tools\Build
System\Components\Platforms\Win32 (x86)\Directories doesn't
exist. This has the effect of not getting the correct
include directories for builds.

This also points out a serious flaw in looking at
undocumented registry entries to find information for the
build -- there's no guarantee that the registry information
won't change even within the same version of the compiler. I
don't have a good solution for this problem, but I'd rather
distutils reported an error when it couldn't find the
registry entries it expected -- rather than silently
ignoring it as it does now. In a few places I added code to
report unexpected missing registry entries, but not all. I
could if you're interested add error code in all cases.

Fixing the problem I'm having with the version 6 compiler
seems difficult, since it seems to work for you and doesn't
work for me -- apparently are registries are different.
Personally I'm content with leaving the version 6 compiler
broken since it isn't obvious how to fix it and it
apparently works for some people and I only intend to use
the version 7 or newer compilers.

I added three new functions: convert_mbcs, read_key, and by
far the largest: expand_macros. The first two make the code
simpler, easier to read, avoid unnecessary duplications, and
minimize the risk that someone would forget to deal with
mbcs. It would be difficult to understand the bug fix
without these two functions. My hope was that these changes
would make it easier for the next person who needs to learn
the code. The last, expand_macros, is necessary because the
version 7 compiler introduces macros which didn't exist in
previous versions of the compiler. It would be awkward to
implement the macros without having adding a new function.
History
Date User Action Args
2007-08-23 15:15:33adminlinkissue614770 messages
2007-08-23 15:15:33admincreate