PSA: VS 2015 is now default Windows compiler

[Bruce Dawson]

A change that (again) makes VS 2015 the default compiler on Windows just landed. The CL is:

https://codereview.chromium.org/1740583002

All known issues have been addressed by using a pre-release version of Update 2 that fixes some code-gen bugs and linker instability. The code-gen bugs should not hit non-PGO builds, and the linker instability is rare, so those using Update 1 of VS 2015 should be fine for now. Using VS 2015 RTM is not supported - it has too many bugs.

Any questions? Ask me. But I'll be AFK for 6-7 hours - it's late here - but will check in at PST morning.

If you want to continue using VS 2013 you can temporarily do this with:

set GYP_MSVS_VERSION=2013

gclient runhooks

This won't work long-term, because eventually we will check in code that requires VS 2015. However we should try to avoid doing that initially, in case we have to revert for some reason.

Bruce Dawson

[Anand]

Any idea how long it will be until we're MSVS2015-only?

[Shinya]

Yay!

I hope it go well this time.

[Bruce Dawson]

This change failed to stick due to problems with .isolate tests on gn builds. Investigating.

[Bruce Dawson]

A change that (once again) makes VS 2015 the default compiler on Windows landed 3 hours ago and it appears to be holding. The CL is:

https://codereview.chromium.org/1783773004

All known issues have been addressed by using a pre-release version of Update 2 that fixes some code-gen bugs and linker instability. The code-gen bugs should not hit non-PGO builds, and the linker instability is rare (and hits debug builds only), so those using Update 1 of VS 2015 should be fine for now. Using VS 2015 RTM is not supported - it has too many bugs, and Update 2 should be used when it is released.

The landmines cause the out directory to be deleted when crossing the CL boundary. On some of my machines this step failed. If that happens you need to manually delete the out directory and run "gclient sync" again.

Any questions? Ask me.

If you want to continue using VS 2013 you can temporarily do this with:

set GYP_MSVS_VERSION=2013

gclient runhooks

This won't work long-term, because eventually we will check in code that requires VS 2015. However we should try to avoid doing that initially, in case we have to revert for some reason.

Full details and the gory history can be found in the tracking bug at crbug.com/440500

[Dirk Pranke]

Excellent!

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Bruce Dawson]

stanisc@ noticed that mini_installer (probably only with component builds) hits problems. They can be worked around by manually copying vcrumtine140*.dll to the temp destination. I'll work on a fix for this. Here are the bug details:

New issue 594294 by sta...@chromium.org: Mini_installer fails to after upgrading to the latest wintoolchain
https://bugs.chromium.org/p/chromium/issues/detail?id=594294

What steps will reproduce the problem? 
(1) Synced the latest source and ran gclient sync which installed wintoolchain 
(2) Build mini_installer 
(3) Run mini_installer on a test Windows 10 laptop 

What is the expected output? What do you see instead? 

Running mini_installer generates the following error: 
The program can't start because VCRUNTIME140.dll is missing from your computer... 

It appears this DLL is missing in the temporary directory where mini_installer unpacks setup files. Adding this DLL manually and rerunning the setup seems to work.

[Ben Goodger (Google)]

I'm not sure if it's related to this, but I synced and built and now in the VS2013 debugger I can't see the contents of strings in the watch panel...

-Ben

On Fri, Mar 11, 2016 at 2:53 PM, Bruce Dawson <bruce...@chromium.org> wrote:

[Bruce Dawson]

Could well be related, especially if you build with win_fastlink (/debug:fastlink), as VS 2013 doesn't really know what to do with those PDBs.

It's worth upgrading to the VS 2015 IDE - the new Intellisense engine is better and there are some nice new debugging and profiling features. One that I'm quite liking is the display of how long each single-step takes - crude profiling while you debug.

[Peter Kasting]

On Sun, Mar 13, 2016 at 5:27 PM, Bruce Dawson <bruce...@chromium.org> wrote:

It's worth upgrading to the VS 2015 IDE - the new Intellisense engine is better and there are some nice new debugging and profiling features. One that I'm quite liking is the display of how long each single-step takes - crude profiling while you debug.

Incidentally, for Google employees, I think the best route to do this currently is to just manually install the (free) VS 2015 Community edition.  I have submitted a request for the Pro version to be added to the same place you can currently get VS 2013 Pro from, but honestly I doubt most people really need Pro anyway.

PK

[Bruce Dawson]

I've also used VS 2015 Community Edition to build Chrome on my home laptop, so from a capabilities point of view (building and debugging) it works perfectly for non-Google employees as well. I can't speak to the licensing terms for Community Edition however.

[Bruce Dawson]

The mini_installer issues I mentioned on Friday have been resolved. The only known VS 2015 issue remaining is crbug.com/594360 (chrome_elf_unittests broken in component builds after VS2015 switch) and that should not block anyone.

So, all systems go. Any questions, contact me.