fix issue 18352 - [REG 2.078] dmd can't generate 64-bit binaries on Windows #7827
Conversation
…indows 10 with VS 2015 checking the KitsRoot10 lib folder is not good enough to detect the SDK, it might just contain the UCRT
| @@ -1046,7 +1046,7 @@ version (Windows) | |||
| if (WindowsSdkDir is null) | |||
| { | |||
| WindowsSdkDir = GetRegistryString(r"Microsoft\Windows Kits\Installed Roots", "KitsRoot10"); | |||
| if (WindowsSdkDir && !FileName.exists(FileName.combine(WindowsSdkDir, "Lib"))) | |||
| if (WindowsSdkDir && !findLatestSDKDir(FileName.combine(WindowsSdkDir, "Include"), r"um\windows.h")) | |||
There was a problem hiding this comment.
All the hipsters use backticks nowadays ;-)
(FWIW the two alternative ways of doing WYSIWYG strings seem to be yet another historical baggage of D)
There was a problem hiding this comment.
Also the same logic is used here too:
Lines 1080 to 1084 in 3835543
Might make sense to avoid duplications as this code seems to be highly susceptible to failures.
There was a problem hiding this comment.
WindowsSdkVersion is no longer used after #7828, so this copy can be removed later.
|
Any way we can ensure on AppVeyor on auto-tester that this doesn't regress in the future? |
Only by uninstalling all Windows 10 SDKs from the Appveyor image, so not really realistic. |
… 10 with VS 2015
checking the KitsRoot10 lib folder is not good enough to detect the SDK, it might just contain the UCRT. Mimick vcvarsall.bat and verify that windows.h exists aswell.