Make VS 2017 the default compiler on Windows

[Bruce Dawson]

Currently Chrome on Windows builds with VS 2015. We are thinking of switching to VS 2017. See this CL for details:

https://chromium-review.googlesource.com/c/chromium/src/+/665637

Any comments? You can reply here or on the CL.

Note that the long-term plan is still to switch to clang, but changing VS versions is still relevant because when we switch to clang we will still be using the VS linker and header files.

[Daniel Bratell]

On Wed, 13 Sep 2017 21:50:58 +0200, Bruce Dawson <bruce...@chromium.org> wrote:

Currently Chrome on Windows builds with VS 2015. We are thinking of switching to VS 2017. See this CL for details:

https://chromium-review.googlesource.com/c/chromium/src/+/665637

Any comments? You can reply here or on the CL.

Will VS2015 stop working right away or will it happen organically one commit at a time? Just asking because there might be a bit of logistics when switching so the softer transition the less risk for someone missing the right compiler at a critical moment.

/Daniel

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Bruce Dawson]

The change is just a matter of changing one line in build\vs_toolchain.py so that the default compiler is VS 2017. It will still be possible to force VS 2015 to be the compiler.

But! I would expect that VS 2017 dependent changes will start landing within a week. I have a few constexpr fixes that I'd love to land, for instance. So VS 2015 probably won't continue to work for very long.

Looked at the other way, VS 2017 has been working well for a few months now so you can start switching to VS 2017 today (I've been using it as my default compiler for quite a while). This is the magic, for those who don't know:

> set GYP_MSVS_VERSION=2017

> gclient runhooks

> gn gen ...

So, give VS 2017 a try today and let us know if switching seems reasonable? And we'll try to avoid checking in VS 2017 dependencies too quickly?

Note that a Windows 10 SDK switch is also imminent. We currently support both 14393 and 15063 but we'd like to start depending on 15063. Switching to VS 2017 will move most people to 15063, and then I'd like to start requiring it sometime next week, so that we can use Creators Update features without difficulty.

[Bruce Dawson]

This change will be landing soon, making VS 2017 the default compiler on Windows.

When installing VS 2017 remember that you have to explicitly select C++ and MFC - neither one is installed by default. Instructions can be found here:

https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Visual-Studio

In particular, after downloading the installer you can run it like this to get the required components:

vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended

Unfortunately the errors from "gclient runhooks" if you don't have VS 2017 installed are a bit cryptic. If the change sticks then I'll make them more specific and helpful.

[Bruce Dawson]

media_unittests started failing and renderer_side_navigation_headless_browsertests started failing intermittently with this change. I'll try to investigate but may need to revert.

https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds/15967

Some deqp tests also failed to a previously discovered compiler bug that we know how to work around.

[Bruce Dawson]

The deqp test failures were easily resolved (thanks Jamie) but the failures in media_unittests will take more investigation. In particular, vpx_internal_error is being called and is crashing. I assumed that the bug was that it was being called, but it appears that the bug is that it is crashing. In VS 2015 it is called and then everything continues after some longjmp fun-and-games.

Reverting while I inquire about what's going on. VS 2015 is once again the default compiler.

[Bruce Dawson]

The media_unittests were fixed (crbug.com/766236) and the other failures were determined to not be VS 2017 related so we'll be trying the switch to VS 2017 again tonight.

See the earlier email in this thread for instructions on how to stay on VS 2015 for a little while, but it is anticipated that that will not remain viable for very long. However please don't land VS 2017-dependent changes for a little while in case we need to revert for some reason.

[Bruce Dawson]

So far it looks like the transition has gone smoothly. I will check crash rates Monday. I'm sure there will be some size and performance regressions, but also some improvements, so I think this change is going to stick.

If you have any questions or concerns you can either reply here or you can comment on the master bug, crbug.com/683729