VS2013 Update 2

VS2013 Update 2

As discussed in the linked bug, the toolchain2013.py script in
depot_tools is no longer workable (because the update for Update 2 is
supplied as a .msp that must be applied against a system-installed
VS2013).

As such, the Express hash here is not updated.

The hash zip referenced here was built as follows:
- Install VS2013 Update 2 on a clean VM
- Copy DIA SDK\, VC\
- Copy DLLs from VC\redist to sys32\ and sys64\
- Copy win8sdk unchanged from previous .zip.
- Delete various unused arm\ subdirectories
- Delete the IDE-only Snippets, etc. subdirectories in VC\
- Patch VC\include\xtree to disable warning 4702 per request in
  http://crbug.com/346399 .

A followup change will be to write a script that does these steps
semi-automatically, hopefully for Express too, though there is the
added complication of the WDK/ATL/MFC hacking required there. In
particular, this script will not be useful for a dev to actually run
as part of runhooks, but will be a bit useful for deployment/
documentation of the above process.

In the interim there are no extremely-pressing reasons for Express
users to update to Update2 that I'm aware of, so they get non-Update2
for now.

R=iannucci@chromium.org
BUG=372451, 346399, 371847, 339215, 350639
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=271721

[scottmg, 2014-05-12 21:42:41]

(it's still uploading to gs:// but should be able to trybot/cq as a normal CL)

https://codereview.chromium.org/284663003/diff/20001/build/get_landmines.py
File build/get_landmines.py (right):

https://codereview.chromium.org/284663003/diff/20001/build/get_landmines.py#n...
build/get_landmines.py:51: print "Update to VS2013 Update 2."
the pdbs require a clobber, this makes sense, right? it'll exist/not when this
updated hash does and so will cause a clobber when it crosses this edge?

[scottmg, 2014-05-12 23:03:30]

landmines seems to be right.

I also removed all the pdb hacking and did a local build of the large test
binaries without component=shared_library but with symbols, and happily it seems
OK. So there's a pretty strong chance the pdb flake will be resolved.

[iannucci, 2014-05-12 23:07:41]

yay for less hacks. lgtm. Looking forward to a script to produce the bundle :)

[scottmg, 2014-05-12 23:10:55]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2014-05-12 23:12:23]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/scottmg@chromium.org/284663003/40001

[scottmg, 2014-05-12 23:23:32]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2014-05-12 23:25:03]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/scottmg@chromium.org/284663003/50001

[scottmg, 2014-05-12 23:35:35]

The CQ bit was unchecked by scottmg@chromium.org

[scottmg, 2014-05-12 23:35:36]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2014-05-12 23:36:24]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/scottmg@chromium.org/284663003/50001

[scottmg, 2014-05-13 01:31:12]

The CQ bit was unchecked by scottmg@chromium.org

[scottmg, 2014-05-13 01:33:36]

Not committing yet pending confirmation from goma team that it's not going to
nuke something. It complains that:

E:\b\depot_tools\python276_bin\python.exe E:\b\build\goma\goma_ctl.py stat
request: total=23732 success=23728 failure=0
 goma: finished=23374 cache_hit=3818 aborted=231 retry=1149 fail=4
 local: run=759 killed=397 finished=127
version_mismatch: local:cl.exe 18.00.30501
(0669953b4b5f20289d059a82ef0414966ae40056f77c442c8d5f6a41c47b2948) but
remote:cl.exe 18.00.21005.1
(214bbaee621b781f568d2624dd81ca4cf5f0c42a397e6ebcf5b85f888c110b0e) 679
 local:cl.exe 18.00.30501
(661298d4928b9abe33fe55c488d6ba447216812471199ea4952d67088276e516) but
remote:cl.exe 18.00.21005.1
(cb5833308051c3fe3c551b9626816b4db9e10ba13562a1d66bbe953079af8767) 18782

binary_hash_mismatch: local:cl.exe 18.00.30501
(0669953b4b5f20289d059a82ef0414966ae40056f77c442c8d5f6a41c47b2948) but
remote:cl.exe 18.00.21005.1
(214bbaee621b781f568d2624dd81ca4cf5f0c42a397e6ebcf5b85f888c110b0e) 679
 local:cl.exe 18.00.30501
(661298d4928b9abe33fe55c488d6ba447216812471199ea4952d67088276e516) but
remote:cl.exe 18.00.21005.1
(cb5833308051c3fe3c551b9626816b4db9e10ba13562a1d66bbe953079af8767) 18782

files: requested=6266072 uploaded=73408 missed=0
memory: consuming=1234219008
http_rpc: query=4987 retry=0 timeout=0 error=2

but I'm not sure what the fallback behaviour actually is (build with wrong one?
build locally?)

[shinyak, 2014-05-13 08:00:43]

Hi scott,

it looks VS2013 (un-updated) compiler is used.

As I mailed to you, VS2013-update2 is not working with goma now.
I've started working for it...

[scottmg, 2014-05-20 18:43:21]

goma seems ok now, so I'm going to land this.

[scottmg, 2014-05-20 18:43:25]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2014-05-20 18:44:32]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/scottmg@chromium.org/284663003/50001

[commit-bot: I haz the power, 2014-05-20 19:15:38]

Change committed as 271721