Reland of win: Update to Win 10 SDK

Reland of win: Update to Win 10 SDK (patchset #1 id:1 of https://codereview.chromium.org/1410153007/ )

Reason for revert:
Relanding, we think all bots are updated now.

Original issue's description:
> Revert of win: Update to Win 10 SDK (patchset #8 id:140001 of https://codereview.chromium.org/1378153003/ )
>
> Reason for revert:
> This is a suspect in breaking Win bots (e.g. here http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20Builder/builds/93039)
>
> Original issue's description:
> > win: Update to Win 10 SDK
> >
> > Tested on clean Win7 VM against both VS2013 and clang=1 at 247874-1.
> >
> > R=brucedawson@chromium.org
> > BUG=491424
> >
> > Committed: https://crrev.com/3f6f89251dc210b24a36398237d374a87d4a3b33
> > Cr-Commit-Position: refs/heads/master@{#352667}
> >
> > Committed: https://crrev.com/1feffb4b7b1c2bfaf112a8993ae7ab0c16a52da9
> > Cr-Commit-Position: refs/heads/master@{#356373}
>
> TBR=brucedawson@chromium.org,sky@chromium.org,scottmg@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=491424
>
> Committed: https://crrev.com/e4a933bfce1dce211b29c392a681513a9d69a85c
> Cr-Commit-Position: refs/heads/master@{#356484}

TBR=brucedawson@chromium.org,sky@chromium.org,caseq@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=491424
Committed: https://crrev.com/510a9e822cf893ec133f1f48643fbf913c24d8c1
Cr-Commit-Position: refs/heads/master@{#363257}

[scottmg, 2015-12-04 18:40:19]

Created Reland of win: Update to Win 10 SDK

[commit-bot: I haz the power, 2015-12-04 18:43:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1502563003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1502563003/1

[commit-bot: I haz the power, 2015-12-04 18:46:26]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-12-04 18:47:15]

Description was changed from

==========
Reland of win: Update to Win 10 SDK (patchset #1 id:1 of
https://codereview.chromium.org/1410153007/ )

Reason for revert:
Relanding, we think all bots are updated now.

Original issue's description:
> Revert of win: Update to Win 10 SDK (patchset #8 id:140001 of
https://codereview.chromium.org/1378153003/ )
> 
> Reason for revert:
> This is a suspect in breaking Win bots (e.g. here
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20Builder/b...)
> 
> Original issue's description:
> > win: Update to Win 10 SDK
> >
> > Tested on clean Win7 VM against both VS2013 and clang=1 at 247874-1.
> >
> > R=brucedawson@chromium.org
> > BUG=491424
> >
> > Committed: https://crrev.com/3f6f89251dc210b24a36398237d374a87d4a3b33
> > Cr-Commit-Position: refs/heads/master@{#352667}
> >
> > Committed: https://crrev.com/1feffb4b7b1c2bfaf112a8993ae7ab0c16a52da9
> > Cr-Commit-Position: refs/heads/master@{#356373}
> 
> TBR=brucedawson@chromium.org,sky@chromium.org,scottmg@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=491424
> 
> Committed: https://crrev.com/e4a933bfce1dce211b29c392a681513a9d69a85c
> Cr-Commit-Position: refs/heads/master@{#356484}

TBR=brucedawson@chromium.org,sky@chromium.org,caseq@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=491424
==========

to

==========
Reland of win: Update to Win 10 SDK (patchset #1 id:1 of
https://codereview.chromium.org/1410153007/ )

Reason for revert:
Relanding, we think all bots are updated now.

Original issue's description:
> Revert of win: Update to Win 10 SDK (patchset #8 id:140001 of
https://codereview.chromium.org/1378153003/ )
>
> Reason for revert:
> This is a suspect in breaking Win bots (e.g. here
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20Builder/b...)
>
> Original issue's description:
> > win: Update to Win 10 SDK
> >
> > Tested on clean Win7 VM against both VS2013 and clang=1 at 247874-1.
> >
> > R=brucedawson@chromium.org
> > BUG=491424
> >
> > Committed: https://crrev.com/3f6f89251dc210b24a36398237d374a87d4a3b33
> > Cr-Commit-Position: refs/heads/master@{#352667}
> >
> > Committed: https://crrev.com/1feffb4b7b1c2bfaf112a8993ae7ab0c16a52da9
> > Cr-Commit-Position: refs/heads/master@{#356373}
>
> TBR=brucedawson@chromium.org,sky@chromium.org,scottmg@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=491424
>
> Committed: https://crrev.com/e4a933bfce1dce211b29c392a681513a9d69a85c
> Cr-Commit-Position: refs/heads/master@{#356484}

TBR=brucedawson@chromium.org,sky@chromium.org,caseq@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=491424

Committed: https://crrev.com/510a9e822cf893ec133f1f48643fbf913c24d8c1
Cr-Commit-Position: refs/heads/master@{#363257}
==========

[commit-bot: I haz the power, 2015-12-04 18:47:18]

Patchset 1 (id:??) landed as
https://crrev.com/510a9e822cf893ec133f1f48643fbf913c24d8c1
Cr-Commit-Position: refs/heads/master@{#363257}

[mmenke, 2015-12-08 21:08:24]

mmenke@chromium.org changed reviewers:
+ mmenke@chromium.org

[mmenke, 2015-12-08 21:08:25]

https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
build/common.gypi:3339: ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
Hardcoding the version number seems very problematic.

When my builds started failing locally, I identified the issue as needing the
Win 10 SDK was fast and easy.  Figuring out that compilation still wasn't
working because the Windows 10 SDK installed to the 10.0.10586.0 subdirectory
instead of this one took a lot longer.

[mmenke, 2015-12-08 21:09:45]

https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py
File build/vs_toolchain.py (right):

https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py#newco...
build/vs_toolchain.py:235: default_sdk_path = 'C:\\Program Files (x86)\\Windows
Kits\\8.1'
Should this be updated?

[scottmg, 2015-12-08 21:10:05]

On 2015/12/08 21:08:25, mmenke wrote:
> https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> File build/common.gypi (right):
> 
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> build/common.gypi:3339: ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> Hardcoding the version number seems very problematic.
> 
> When my builds started failing locally, I identified the issue as needing the
> Win 10 SDK was fast and easy.  Figuring out that compilation still wasn't
> working because the Windows 10 SDK installed to the 10.0.10586.0 subdirectory
> instead of this one took a lot longer.

Why did your builds fail locally? How are you building?

[mmenke, 2015-12-08 21:14:17]

On 2015/12/08 21:10:05, scottmg wrote:
> On 2015/12/08 21:08:25, mmenke wrote:
> > https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> > File build/common.gypi (right):
> > 
> >
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> > build/common.gypi:3339: ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> > Hardcoding the version number seems very problematic.
> > 
> > When my builds started failing locally, I identified the issue as needing
the
> > Win 10 SDK was fast and easy.  Figuring out that compilation still wasn't
> > working because the Windows 10 SDK installed to the 10.0.10586.0
subdirectory
> > instead of this one took a lot longer.
> 
> Why did your builds fail locally? How are you building?

windows_finder_win failed to compiled because it didn't find
IVirtualDesktopManager.  Initially, I got this error because I was still using
the win 8 SDK.  The comment just above made it clear I needed the Win 10 SDK.  I
installed that, and still got the same error.

I'm off corp, using MSVS 2013, with a manually installed Win 8.1 SDK (I think?).
 I did not have WINDOWSSDKDIR set, though setting it made no difference.

Also odd that it was using the 8.1 SDK, rather than just hard failing, not sure
why that is.

[mmenke, 2015-12-08 21:17:37]

Currently, looks like ninja is using mt.exe from my 8.1 SDK install, and the
headers from my 10 SDK install...  I assume the line I pointed out is the
reason?

[mmenke, 2015-12-08 21:20:47]

On 2015/12/08 21:14:17, mmenke wrote:
> On 2015/12/08 21:10:05, scottmg wrote:
> > On 2015/12/08 21:08:25, mmenke wrote:
> > > https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> > > File build/common.gypi (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> > > build/common.gypi:3339: ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> > > Hardcoding the version number seems very problematic.
> > > 
> > > When my builds started failing locally, I identified the issue as needing
> the
> > > Win 10 SDK was fast and easy.  Figuring out that compilation still wasn't
> > > working because the Windows 10 SDK installed to the 10.0.10586.0
> subdirectory
> > > instead of this one took a lot longer.
> > 
> > Why did your builds fail locally? How are you building?
> 
> windows_finder_win failed to compiled because it didn't find
> IVirtualDesktopManager.  Initially, I got this error because I was still using
> the win 8 SDK.  The comment just above made it clear I needed the Win 10 SDK. 
I
> installed that, and still got the same error.
> 
> I'm off corp, using MSVS 2013, with a manually installed Win 8.1 SDK (I
think?).
>  I did not have WINDOWSSDKDIR set, though setting it made no difference.
> 
> Also odd that it was using the 8.1 SDK, rather than just hard failing, not
sure
> why that is.

Not sure it's relevant, but I'm using my personal copy of MSVC 2013
professional.

[scottmg, 2015-12-08 21:20:58]

https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py
File build/vs_toolchain.py (right):

https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py#newco...
build/vs_toolchain.py:235: default_sdk_path = 'C:\\Program Files (x86)\\Windows
Kits\\8.1'
On 2015/12/08 21:09:45, mmenke wrote:
> Should this be updated?

Yes, probably. Are you building with GN? Otherwise it's unused (according to the
comment anyway)

[scottmg, 2015-12-08 21:22:20]

On 2015/12/08 21:20:47, mmenke wrote:
> On 2015/12/08 21:14:17, mmenke wrote:
> > On 2015/12/08 21:10:05, scottmg wrote:
> > > On 2015/12/08 21:08:25, mmenke wrote:
> > > > https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> > > > File build/common.gypi (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> > > > build/common.gypi:3339: ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> > > > Hardcoding the version number seems very problematic.
> > > > 
> > > > When my builds started failing locally, I identified the issue as
needing
> > the
> > > > Win 10 SDK was fast and easy.  Figuring out that compilation still
wasn't
> > > > working because the Windows 10 SDK installed to the 10.0.10586.0
> > subdirectory
> > > > instead of this one took a lot longer.
> > > 
> > > Why did your builds fail locally? How are you building?
> > 
> > windows_finder_win failed to compiled because it didn't find
> > IVirtualDesktopManager.  Initially, I got this error because I was still
using
> > the win 8 SDK.  The comment just above made it clear I needed the Win 10
SDK. 
> I
> > installed that, and still got the same error.
> > 
> > I'm off corp, using MSVS 2013, with a manually installed Win 8.1 SDK (I
> think?).
> >  I did not have WINDOWSSDKDIR set, though setting it made no difference.
> > 
> > Also odd that it was using the 8.1 SDK, rather than just hard failing, not
> sure
> > why that is.
> 
> Not sure it's relevant, but I'm using my personal copy of MSVC 2013
> professional.

OK. DEPOT_TOOLS_WIN_TOOLCHAIN=0 isn't tested anywhere, so there's a good chance
it's broken.

[mmenke, 2015-12-08 21:25:06]

On 2015/12/08 21:20:58, scottmg wrote:
> https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py
> File build/vs_toolchain.py (right):
> 
>
https://codereview.chromium.org/1502563003/diff/1/build/vs_toolchain.py#newco...
> build/vs_toolchain.py:235: default_sdk_path = 'C:\\Program Files
(x86)\\Windows
> Kits\\8.1'
> On 2015/12/08 21:09:45, mmenke wrote:
> > Should this be updated?
> 
> Yes, probably. Are you building with GN? Otherwise it's unused (according to
the
> comment anyway)

No, I'm building with MSVC ninja.  As part of the debugging process, I renamed
my 8.1 directory, and it complained that mt.exe was missing until I reverted the
name change.  I suppose I may have renamed it after I ran gclient runhooks, but
the project I build is otherwise using the win 10 SDK, now (I made a copy of the
10.0.10586.0 SDK directory, and called it 10.0.10240.0...Lovely solution, but I
couldn't find an easy way to download the older one).

[mmenke, 2015-12-08 21:27:00]

On 2015/12/08 21:22:20, scottmg wrote:
> On 2015/12/08 21:20:47, mmenke wrote:
> > On 2015/12/08 21:14:17, mmenke wrote:
> > > On 2015/12/08 21:10:05, scottmg wrote:
> > > > On 2015/12/08 21:08:25, mmenke wrote:
> > > > > https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> > > > > File build/common.gypi (right):
> > > > > 
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> > > > > build/common.gypi:3339:
['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> > > > > Hardcoding the version number seems very problematic.
> > > > > 
> > > > > When my builds started failing locally, I identified the issue as
> needing
> > > the
> > > > > Win 10 SDK was fast and easy.  Figuring out that compilation still
> wasn't
> > > > > working because the Windows 10 SDK installed to the 10.0.10586.0
> > > subdirectory
> > > > > instead of this one took a lot longer.
> > > > 
> > > > Why did your builds fail locally? How are you building?
> > > 
> > > windows_finder_win failed to compiled because it didn't find
> > > IVirtualDesktopManager.  Initially, I got this error because I was still
> using
> > > the win 8 SDK.  The comment just above made it clear I needed the Win 10
> SDK. 
> > I
> > > installed that, and still got the same error.
> > > 
> > > I'm off corp, using MSVS 2013, with a manually installed Win 8.1 SDK (I
> > think?).
> > >  I did not have WINDOWSSDKDIR set, though setting it made no difference.
> > > 
> > > Also odd that it was using the 8.1 SDK, rather than just hard failing, not
> > sure
> > > why that is.
> > 
> > Not sure it's relevant, but I'm using my personal copy of MSVC 2013
> > professional.
> 
> OK. DEPOT_TOOLS_WIN_TOOLCHAIN=0 isn't tested anywhere, so there's a good
chance
> it's broken.

Ahh, yes, I do have that set up.  Should I remove it, or would things just fail
in other exciting ways if I did?  I added it when things broke without it a year
or so back, I believe.  :(

[scottmg, 2015-12-08 21:30:07]

On 2015/12/08 21:27:00, mmenke wrote:
> On 2015/12/08 21:22:20, scottmg wrote:
> > On 2015/12/08 21:20:47, mmenke wrote:
> > > On 2015/12/08 21:14:17, mmenke wrote:
> > > > On 2015/12/08 21:10:05, scottmg wrote:
> > > > > On 2015/12/08 21:08:25, mmenke wrote:
> > > > > > https://codereview.chromium.org/1502563003/diff/1/build/common.gypi
> > > > > > File build/common.gypi (right):
> > > > > > 
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://codereview.chromium.org/1502563003/diff/1/build/common.gypi#newcode3339
> > > > > > build/common.gypi:3339:
> ['<(windows_sdk_path)/Lib/10.0.10240.0/um/x86'],
> > > > > > Hardcoding the version number seems very problematic.
> > > > > > 
> > > > > > When my builds started failing locally, I identified the issue as
> > needing
> > > > the
> > > > > > Win 10 SDK was fast and easy.  Figuring out that compilation still
> > wasn't
> > > > > > working because the Windows 10 SDK installed to the 10.0.10586.0
> > > > subdirectory
> > > > > > instead of this one took a lot longer.
> > > > > 
> > > > > Why did your builds fail locally? How are you building?
> > > > 
> > > > windows_finder_win failed to compiled because it didn't find
> > > > IVirtualDesktopManager.  Initially, I got this error because I was still
> > using
> > > > the win 8 SDK.  The comment just above made it clear I needed the Win 10
> > SDK. 
> > > I
> > > > installed that, and still got the same error.
> > > > 
> > > > I'm off corp, using MSVS 2013, with a manually installed Win 8.1 SDK (I
> > > think?).
> > > >  I did not have WINDOWSSDKDIR set, though setting it made no difference.
> > > > 
> > > > Also odd that it was using the 8.1 SDK, rather than just hard failing,
not
> > > sure
> > > > why that is.
> > > 
> > > Not sure it's relevant, but I'm using my personal copy of MSVC 2013
> > > professional.
> > 
> > OK. DEPOT_TOOLS_WIN_TOOLCHAIN=0 isn't tested anywhere, so there's a good
> chance
> > it's broken.
> 
> Ahh, yes, I do have that set up.  Should I remove it, or would things just
fail
> in other exciting ways if I did?  I added it when things broke without it a
year
> or so back, I believe.  :(

If you don't have any great reason to use it, then yes, it would be better to
not set that variable. All the bots and most win devs use the "other" path, so
you're at least on a more well worn path, and it should be easier to figure out
any problems with that case.

On the other hand, if you want to fix the DEPOT_TOOLS_WIN_TOOLCHAIN=0 path, it'd
be nice to fix whatever's broken.

[brucedawson, 2015-12-09 19:25:13]

I opened crbug.com/568201 to track this.