Improve windows sdk lookup logic in WindowsToolChain.cc

[nico]

Bugzilla Link	11792
Resolution	FIXED
Resolved on	Jul 26, 2014 14:22
Version	unspecified
OS	Windows NT
Blocks	llvm/llvm-bugzilla-archive#13707
Attachments	patch sketch
CC	@tritao,@timurrrr

Extended Description

I somehow ended up with a registry that looks like

.../Microsoft SDKs/Windows/
v7.0A/
InstallationFolder
(tons of subfolders
v7.1
(no values)
Just WinSDKIntelliSysRefAssist

So for some reason I don't have a real v7.1 SDK. The current toolchain looks for the highest version first, and after that for "InstallationFolder" in there.

Instead, it should pick the highest version with "InstallationFolder" present. A rough sketch of a patch is attached.

[tritao]

Can you submit the finished patch to the list?

[llvmbot]

r152589 has introduced %INCLUDE%.
At least, "Command prompt for Visual Studio" provides sdkdir in %INCLUDE%.

Shall we detect sdk dirs anyways?
Does CL.EXE seek system-known sdk dirs?

[tritao]

I think we should still detect the SDK directories, and default on the latest toolset if the environment variables are not found.

[tritao]

I started working a bit on improving the Windows driver stuff. Attached is a work-in-progress patch that:

• Refactors the registry lookup code
• Adds the improved SDK lookup patch on this bug
• Adds MS C++ standard library support
• Enables MS ABI automatically when targetting the MS C++ libs
• Also temporarily disables RTTI by default since it does not work yet

[tritao]

MS driver improvements

[nico]

I feel that it would be useful if the registry code could be tested somehow (maybe by having a test binary that creates an fake memory from yaml files or some such), before it's refactored.

[nico]

r160702 does not have this problem yet.

[nico]

sorry, comment 7 was for a different bug

[nico]

Looks like Hans landed something like my patch sketch in r192374.

[tritao]

mentioned in issue llvm/llvm-bugzilla-archive#13707