PSA: VS 2015 is now default Windows compiler

150 views
Skip to first unread message

Bruce Dawson

unread,
Mar 10, 2016, 4:27:51 AM3/10/16
to Chromium-dev
A change that (again) makes VS 2015 the default compiler on Windows just landed. The CL is:


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

unread,
Mar 10, 2016, 4:30:43 AM3/10/16
to Chromium-dev
Any idea how long it will be until we're MSVS2015-only?

Shinya

unread,
Mar 10, 2016, 4:49:14 AM3/10/16
to Chromium-dev
Yay!

I hope it go well this time.

Bruce Dawson

unread,
Mar 10, 2016, 1:24:09 PM3/10/16
to Chromium-dev
This change failed to stick due to problems with .isolate tests on gn builds. Investigating.

Bruce Dawson

unread,
Mar 11, 2016, 5:54:59 PM3/11/16
to Chromium-dev
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:


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

unread,
Mar 11, 2016, 6:51:56 PM3/11/16
to Bruce Dawson, Chromium-dev
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

unread,
Mar 11, 2016, 7:12:55 PM3/11/16
to Dirk Pranke, Chromium-dev
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)

unread,
Mar 12, 2016, 5:15:55 PM3/12/16
to bruce...@chromium.org, Chromium-dev
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

unread,
Mar 13, 2016, 8:29:02 PM3/13/16
to Ben Goodger (Google), Chromium-dev
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

unread,
Mar 14, 2016, 6:50:13 AM3/14/16
to Bruce Dawson, Ben Goodger (Google), Chromium-dev
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

unread,
Mar 14, 2016, 1:24:33 PM3/14/16
to Peter Kasting, Ben Goodger (Google), Chromium-dev
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

unread,
Mar 14, 2016, 2:36:54 PM3/14/16
to Peter Kasting, Ben Goodger (Google), Chromium-dev
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.
Reply all
Reply to author
Forward
0 new messages