Hit enter too soon...

None of this affects the build machines which are already using 15063. I encountered this on my home machine and hacked around it. Something better would be nice.

Adding a few people to get feedback. Any thoughts on the tradeoffs here? I guess there's no critical hurry.

I think requiring 15063 is probably fine, but you might check on chromium-dev to see if this will cause big problems for any non-Googlers.

Thanks for the heads-up! Updating SDK is not fun. I think the worst part of it is that errors from having a too old (or sometimes a too new) SDK version are hard to track down and time consuming. Not sure if that is anything that is better nowadays?

I just did some experimentation...

If I modify setup_toolchain.py to request 10.0.15063.0 instead of 10.0.14393.0 then if 15063 is not installed there will be no failure during the "gn gen" step, but header files will be missing when I build. That is unfortunate.

The next obvious thing to do is to omit the SDK specifier - that is what we have historically done. We can then use #ifdefs to check whether the correct SDK version is installed. We currently have one that enables the HDR detection feature if the Creators SDK is installed. It would be easy enough to issue a #error if that check fails. See:
https://cs.chromium.org/chromium/src/gpu/ipc/service/direct_composition_surface_win.cc?type=cs&q=NTDDI_WIN10_RS2&sq=package:chromium&l=38

However, neither of these solve the problem of a user who has too-old an SDK installed. They will either hit problems with a missing bits10_1.h (https://developercommunity.visualstudio.com/content/problem/42961/15063-sdk-is-broken-bitsh-indirectly-references-no.html) or, if building with clang-cl, will hit a cryptic error in wrl\events.h - it depends when they installed the SDK. I'm not sure how to detect these errors.


I'm inclined to go with the simplest solution which is to just delete the explicit request for 10.0.14393.0 and call that good. A few people will hit those errors and with luck they will find an acceptable solution.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/48bee70bfbe1f6c0e282968de45ed10d98b73e93

commit 48bee70bfbe1f6c0e282968de45ed10d98b73e93
Author: Bruce Dawson <brucedawson@chromium.org>
Date: Wed Jul 12 18:56:29 2017

Allow building with the Creators Update SDK

When the Creators Update SDK (10.0.15063.0) came out it was buggy so we
locked Chrome builds to to the Anniversary Edition SDK (10.0.14393.0).

However this means that if developers only install the latest SDK they
cannot build Chrome. This is particularly frustrating for developers who
want to build Chrome with VS 2017, which now ships with 10.0.15063.0.

Since the 10.0.15063.468 SDK fixes the bugs this change removes the
SDK limitation. Builds with the local toolchain will now use the latest
SDK version installed. 10.0.14393.0 is the minimum.

Build machine builds are unaffected as they don't use an installed
toolchain.

If you hit a build error with bits10_1.h not being found then install
the latest Windows 10 SDK. If you do a clang build and hit a build error
with undeclared identifier 'DefaultDelegateCheckMode then install the
latest Windows 10 SDK.

The 10.0.15063.0 SDK will probably be required at some point.

I tested this on a machine that has VS 2017 with 15063 installed but
no 14393 SDK. Without the patch there were cryptic failures because
mc.exe and windows.h could not be found at build time. With the patch
the build worked.

BUG= 738640 

Change-Id: Ie74dac40b5b26e19153f173cc2b54e926ee1c917
Reviewed-on: https://chromium-review.googlesource.com/565421
Reviewed-by: bratell at Opera <bratell@opera.com>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486040}
[modify] https://crrev.com/48bee70bfbe1f6c0e282968de45ed10d98b73e93/build/toolchain/win/setup_toolchain.py

Looks like http://crrev.com/475258923fee8ee38edbcd4ad1a86bc5ef6f286a may have added an implicit dependency on the Creators Update SDK:

Traceback (most recent call last):
  File "C:/code/chromium_git2/chromium/src/build/vs_toolchain.py", line 460, in <module>
    sys.exit(main())
  File "C:/code/chromium_git2/chromium/src/build/vs_toolchain.py", line 456, in main
    return commands[sys.argv[1]](*sys.argv[2:])
  File "C:/code/chromium_git2/chromium/src/build/vs_toolchain.py", line 317, in CopyDlls
    _CopyDebugger(target_dir, target_cpu)
  File "C:/code/chromium_git2/chromium/src/build/vs_toolchain.py", line 343, in _CopyDebugger
    '10 SDK.' % (debug_file, full_path))
Exception: dbgcore.dll not found in "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbgcore.dll"
You must install the "Debugging Tools for Windows" feature from the Windows 10 SDK.
ERROR at //build/toolchain/win/BUILD.gn:39:3: Script returned non-zero exit code.

I have the Anniversary Edition SDK installed and dbgcore.dll does not exist (dbghelp.dll does exist).

Do you also have the Creators Update SDK installed? If not then the recent change would not affect you. Any idea what triggered this breakage? The requirement to copy dbgcore.dll was added several weeks ago I believe.

Did you explicitly install the Anniversary Edition SDK, or was it installed implicitly by Visual Studio? Did you install the Debuggers package when you installed the Anniversary Edition SDK?

Given that this is the first report we have had of this issue I suspect that your local install is incorrect.

Ha, weird, all these dependencies varying depending on which version of the SDK you're using are annoying. 

I could make this copy optional (maybe dependent on the DEPOT_TOOLS_WIN_TOOLCHAIN env var)

@brucedawson: This is my first time building past the revision from comment #9. I have the 10.0.14393.0 and 10.0.15063.0 SDKs installed. I also have VS2015 version 14.0.25425.01 Update 3 and VS2017 version 15.2 (26430.16) installed. My "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll" file is version 10.0.14321.1024, but other DLLs in that directory are version 10.0.10586.15.

I just installed the 10.0.15063.468 SDK. It deletes and re-creates the "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\" directory. The dbgcore.dll file now exists and all files are at version 10.0.15063.468.

I filed  crbug.com/748166 .