Windows builds now use clang by default

[Nico Weber]

Hi,

As of #490494, chrome/win builds now use clang as compiler by default. We hope to ship M62 in this configuration.

In general, the compiler switch should be mostly transparent for developers. You will now use clang locally if you build on Windows. You should still be able to use the Visual Studio IDE for debugging, you should still be able to use ETW.

Compiles are a bit slower than with Visual Studio’s compiler if you do local builds. On the other hand, they work better with distributed build systems. If you work for Google and don’t yet use goma, you might want to give it a try (https://go/ma for setup instructions). It’s a bit easier to use if you use Bruce’s autoninja (already in depot_tools and your %PATH%). See https://chromium.googlesource.com/chromium/src/+/lkcr/docs/windows_build_instructions.md#Faster-builds for more options for getting faster builds.

We will keep the Visual Studio build working for a release or two in case we need to switch back. All the “clang” bots now do Visual Studio builds to make sure the Visual Studio build does not bitrot, while the regular bots now do clang builds.

If you run into any problems, please file a bug and cc hans@ and thakis@. You can set is_clang = false to switch back to Visual Studio for now if something’s really not working for you, but only do this after filing a bug.

Nico,

on behalf of the clang/win crew (rnk@ hans@ inglorion@ thakis@)

p.s.: The linker is still link.exe, we’re only changing the compiler at this point.

[PhistucK]

Very cool! Congratulations.

What are the plans for changing the linker?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiFVg-HV2XWeRdwDruHG2PLGY0T9b-H5r6vtQ1ZJ9%2BGWVQ%40mail.gmail.com.

[Charles Harrison]

Amazing milestone! Does this mean we can start removing COMPILER_MSVC #ifdefs after M62 (assuming we ship OK)?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Li2arCfAqKqY8Ku86FW6S1N3c_e9Ynbk8VLHiDYPD4Lg%40mail.gmail.com.

[Hans Wennborg]

Not yet. We want to keep the MSVC build working for at least a couple
of releases, and have buildbots to keep it so.

>>> email to blink-dev+...@chromium.org.

[Hans Wennborg]

Changing the linker will be the next step. We've had builds linked
with lld running on buildbots for a while now, but we think changing
one piece of the toolchain at the time is the best approach.

>> email to blink-dev+...@chromium.org.

[Nico Weber]

On Fri, Jul 28, 2017 at 4:31 PM, Charles Harrison <cshar...@chromium.org> wrote:

Amazing milestone! Does this mean we can start removing COMPILER_MSVC #ifdefs after M62 (assuming we ship OK)?

See "a release or two" -- but if things look good, I'd imagine we'd make compiling with Visual Studio's compiler community-supported like we did with gcc (i.e. we accept patches, but don't use it on the waterfall). Having said that, clang-cl also sets COMPILER_MSVC, just like clang sets COMPILER_GCC.

 

On Fri, Jul 28, 2017 at 4:28 PM, PhistucK <phis...@gmail.com> wrote:

Very cool! Congratulations.

What are the plans for changing the linker?

We're actively working on it. The big missing thing is that lld-link can't completely write pdb files yet. Work on that is underway, but not complete.

 

istuc

On Fri, Jul 28, 2017 at 11:26 PM, Nico Weber <tha...@chromium.org> wrote:

Hi,

As of #490494, chrome/win builds now use clang as compiler by default. We hope to ship M62 in this configuration.

In general, the compiler switch should be mostly transparent for developers. You will now use clang locally if you build on Windows. You should still be able to use the Visual Studio IDE for debugging, you should still be able to use ETW.

Compiles are a bit slower than with Visual Studio’s compiler if you do local builds. On the other hand, they work better with distributed build systems. If you work for Google and don’t yet use goma, you might want to give it a try (https://go/ma for setup instructions). It’s a bit easier to use if you use Bruce’s autoninja (already in depot_tools and your %PATH%). See https://chromium.googlesource.com/chromium/src/+/lkcr/docs/windows_build_instructions.md#Faster-builds for more options for getting faster builds.

We will keep the Visual Studio build working for a release or two in case we need to switch back. All the “clang” bots now do Visual Studio builds to make sure the Visual Studio build does not bitrot, while the regular bots now do clang builds.

If you run into any problems, please file a bug and cc hans@ and thakis@. You can set is_clang = false to switch back to Visual Studio for now if something’s really not working for you, but only do this after filing a bug.

Nico,

on behalf of the clang/win crew (rnk@ hans@ inglorion@ thakis@)

p.s.: The linker is still link.exe, we’re only changing the compiler at this point.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiFVg-HV2XWeRdwDruHG2PLGY0T9b-H5r6vtQ1ZJ9%2BGWVQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Matthew Menke]

This is great!  Do the same checks run on Windows clang as everywhere else, now?  Initializer order, for instance.

[Hans Wennborg]

Yes, win/clang developers will now get the same clang warnings as
other platforms, including warnings from the chromium style-checker
clang plugin.

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/816cd9bd-ce64-4a1a-a2d3-a8cfe5f9ba49%40chromium.org.

[Nico Weber]

On Fri, Jul 28, 2017 at 4:48 PM, Matthew Menke <mme...@google.com> wrote:

This is great!  Do the same checks run on Windows clang as everywhere else, now?  Initializer order, for instance.

To add some more color to what Hans said: In general, we tried to enable most warnings on clang/win that are enabled on other platforms (see blockers on https://crbug.com/504657). And "if a cross-platform cc file compiles on one platform, it should build on all platforms" is certainly an aspirational goal. Having said that, because we need to be able to parse Windows headers, clang-cl accepts some things that clang doesn't accept on other platforms (e.g. https://clang.llvm.org/docs/MSVCCompatibility.html#template-instantiation-and-name-lookup). We try to emit a warning when this happens (https://docs.google.com/presentation/d/1oxNHaVjA9Gn_rTzX6HIpJHP7nXRua_0URXxxJ3oYRq0/edit#slide=id.g71ecd450e_2_812). We enabled most of these warnings in chrome builds by now, but not all of them (e.g. https://crbug.com/550065).

[Dirk Pranke]

Congratulations, this is a truly impressive achievement!

-- Dirk

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[David Finkelstein]

This is most excellent!  Congratulations on this achievement.  The team has been working on this a long time and overcame many challenges to get here.

I'd also like to give a shout-out to the additional LLVM Win crew of zturner@, Adrian, and Rui.

On Fri, Jul 28, 2017 at 1:26 PM, Nico Weber <tha...@chromium.org> wrote:

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMGbLiFVg-HV2XWeRdwDruHG2PLGY0T9b-H5r6vtQ1ZJ9%2BGWVQ%40mail.gmail.com.

[John Abd-El-Malek]

Huge congrats!

The last time we had 10 minute builds on Windows was a decade ago!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKj_HwNYod-rQgwNeUEEhBu09%2BHiPAvw8Z8mSMuNbbajhO46Ng%40mail.gmail.com.

[Peter Kasting]

On Fri, Jul 28, 2017 at 1:26 PM, Nico Weber <tha...@chromium.org> wrote:

As of #490494, chrome/win builds now use clang as compiler by default.

Sustained applause!  This was a tremendous amount of effort and I look forward to the benefits it will bring.  (I'm hoping for Windows xrefs in code search, personally.)

PK

[Carlos Pizano]

This is amazing. Muchos kudos.

What is the sense on the amount of work when updating the Windows SDK? 

[Nico Weber]

When we updated from 2013 to 2015, we (well, rnk) just had to implement the vectorcall calling convention. From 2017, we had to do even less (in part because Microsoft tries to test their new stuff with clang-cl, and they're also making an effort to be more standards compliant). So so far, the SDK switches went smoothly. No way to say how future ones are going to go, of course, but so far so good.

[Daniel Cheng]

Awesome! I'm excited that we don't have to worry about DCHECK() not compiling on Windows anymore =)

Daniel

P.S. dare I ask about cross-compilation?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiEaSFevq-4n_tg-MWpQ_ZK6Gb9GSkDH-0ujZPy%3DHvRWJQ%40mail.gmail.com.

[Nico Weber]

On Jul 28, 2017 10:49 PM, "Daniel Cheng" <dch...@chromium.org> wrote:

Awesome! I'm excited that we don't have to worry about DCHECK() not compiling on Windows anymore =)

Daniel

P.S. dare I ask about cross-compilation?

Cross compiling also needs linker, ninja support, gn support, SDK, rc.exe, cvtres.exe, mt.exe, midl.exe, mc.exe. Having said that, we've been working on it a bit and some smaller binaries build fine with just minor tweaks, see https://chromium-review.googlesource.com/c/584810/ (click "read more" ; also star the linked bug to follow progress). The rietveld version of that patch could at one point link chrome.dll with a bunch of stuff stubbed out. Small binaries will hopefully work without any patches in a few weeks.

[Colin Blundell]

This is an unbelievable achievement and just underscores all of the amazing work that you folks have been doing on clang in Chromium over the past years. Thanks for your efforts, which are making life better for all of us!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiG-EXtxv-%2B4eA7ZSSt5ntDdNoS3t9rJDMOyY9G2OL%3DRJQ%40mail.gmail.com.

[Rong Jie]

Binary size increases after the commit, especially chrome.dll by 4+MB [1]. The problem will be tackled on Clang side or LLD side?

By the way,  indicates that the commit [2] was landed in Chrome 62.0.3170.0 which I am using right now, but chrome://version still says MSVC 2015 (PGO). I was under the impression that ClangOnWin is not compatible with MSVC link.exe PGO.

[1]: https://chromeperf.appspot.com/report?sid=63def557d27e5ca5a15507e81a77624f7374e76f269728a602eecb6496a9d524

[2]: https://storage.googleapis.com/chromium-find-releases-static/d2c.html#d2c91228a51bdf37ae3b2e501fb53c0528f1629c

[Nico Weber]

Yes, binary size on 32-bit goes up. On 64-bit it goes down in return. See https://crbug.com/457078 for many notes on binary size.

The dev channel still receives 50% VC PGO and 50% clang builds, like it's been the case for a while.

It's possible canary is still served off the VC bots. That'd be an oversight; we'll look into it.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/377e8571-4ab5-4861-98a5-485e81de2b3c%40chromium.org.

[Yoichi Osato]

It makes local debug build about 100 times slower...

This is my local debug gn args:

is_component_build = true

enable_nacl = false

is_clang = false

is_win_fastlink = true

target_cpu = "x86"

is_debug = true

I tested with changing just inserts a empty line in a core/*.cpp,

$ ninja content_shell

With is_clang=false, it just takes 7 seconds.

With turning clang on, it takes 600 seconds!

I can't use this.

2017年7月30日(日) 11:19 Nico Weber <tha...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiFFbyEO2VTuqviAnvSpCzmFpNMBJO0aZHJgZ%3Dw5uHDJSA%40mail.gmail.com.

[Yoichi Osato]

It makes local debug build about 100 times slower...

This is my local debug gn args:

is_component_build = true

enable_nacl = false

is_clang = false

is_win_fastlink = true

target_cpu = "x86"

is_debug = true

I tested with changing just inserts a empty line in a core/*.cpp,

$ ninja content_shell

With is_clang=false, it just takes 7 seconds.

With turning clang on, it takes 600 seconds!

I can't use this.

2017年7月30日(日) 11:19 Nico Weber <tha...@chromium.org>:

Yes, binary size on 32-bit goes up. On 64-bit it goes down in return. See https://crbug.com/457078 for many notes on binary size.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiFFbyEO2VTuqviAnvSpCzmFpNMBJO0aZHJgZ%3Dw5uHDJSA%40mail.gmail.com.

[Nico Weber]

On Mon, Jul 31, 2017 at 2:46 AM, Yoichi Osato <yoi...@chromium.org> wrote:

It makes local debug build about 100 times slower...

This is my local debug gn args:

is_component_build = true

enable_nacl = false

is_clang = false

is_win_fastlink = true

target_cpu = "x86"

is_debug = true

I tested with changing just inserts a empty line in a core/*.cpp,

$ ninja content_shell

With is_clang=false, it just takes 7 seconds.

With turning clang on, it takes 600 seconds!

Thanks for the report! MSVC's link.exe /incremental mode doesn't work well for blink_core because it contains so many inline methods. The good news is that this is fixed in MSVC 2017. Please try:

export GYP_MSVS_VERSION=2017

gclient runhooks

and patch in https://chromium-review.googlesource.com/c/593773/ (which will hopefully land today). This seems to fix this locally for me.

We've investigated in some detail what exactly makes /incremental mode not work in https://crbug.com/560475 , and it looks like we might be able to make this work in 2015 as well (and reduce memory use of link.exe with both 2015 and 2017). But for now, I'd suggest opting in to 2017. Please let me know if this doesn't work for you.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[bruce...@chromium.org]

As Nico's comment suggests, VC++ versions still matter to us even though we aren't using their compiler. I would guess that we will probably switch to VC++ 2017 when Update 3 formally ships, if only to get the improved incremental linking support.

[Nico Weber]

On Mon, Jul 31, 2017 at 10:57 AM, Nico Weber <tha...@chromium.org> wrote:

On Mon, Jul 31, 2017 at 2:46 AM, Yoichi Osato <yoi...@chromium.org> wrote:

It makes local debug build about 100 times slower...

This is my local debug gn args:

is_component_build = true

enable_nacl = false

is_clang = false

is_win_fastlink = true

target_cpu = "x86"

is_debug = true

I tested with changing just inserts a empty line in a core/*.cpp,

$ ninja content_shell

With is_clang=false, it just takes 7 seconds.

With turning clang on, it takes 600 seconds!

Thanks for the report! MSVC's link.exe /incremental mode doesn't work well for blink_core because it contains so many inline methods. The good news is that this is fixed in MSVC 2017. Please try:

export GYP_MSVS_VERSION=2017

gclient runhooks

and patch in https://chromium-review.googlesource.com/c/593773/ (which will hopefully land today). This seems to fix this locally for me.

We've investigated in some detail what exactly makes /incremental mode not work in https://crbug.com/560475 , and it looks like we might be able to make this work in 2015 as well (and reduce memory use of link.exe with both 2015 and 2017). But for now, I'd suggest opting in to 2017. Please let me know if this doesn't work for you.

As of #490810, it should just work with MSVC2015 too, in 32-bit builds. (In 64-bit builds, you need MSVC2017, but that's true with both clang-c and Visual Studio's compiler.)

[Rong Jie]

FYI, I am getting clang version of Chrome Canary as expected now.

Is Chromium planning to switch from VC++ standard C++ library to libc++ since other platforms already use libc++? Win10 SDK will still be needed though.

[Hayden Livingston]

Does this mean that LLVM is being used for code-generation of Chromium on Windows? 

[Nico Weber]

On Aug 1, 2017 12:02 AM, "Hayden Livingston" <halivi...@gmail.com> wrote:

Does this mean that LLVM is being used for code-generation of Chromium on Windows?

Yes.

On Monday, July 31, 2017 at 7:45:45 PM UTC-7, Rong Jie wrote:

FYI, I am getting clang version of Chrome Canary as expected now.

Is Chromium planning to switch from VC++ standard C++ library to libc++ since other platforms already use libc++? Win10 SDK will still be needed though.

We haven't looked at this yet. MSVC's c++ stdlib is pretty good. We're currently looking at link.exe, since that allows us to do LTO.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ac68a1f-b5aa-41dc-b336-9982860b4a97%40chromium.org.

[Nico Weber]

On Aug 1, 2017 12:02 AM, "Hayden Livingston" <halivi...@gmail.com> wrote:

Does this mean that LLVM is being used for code-generation of Chromium on Windows? 

Yes.

On Monday, July 31, 2017 at 7:45:45 PM UTC-7, Rong Jie wrote:

FYI, I am getting clang version of Chrome Canary as expected now.

Is Chromium planning to switch from VC++ standard C++ library to libc++ since other platforms already use libc++?

We haven't looked at this yet. MSVC's c++ stdlib is pretty good. We're currently looking at link.exe, since that allows us to do LTO.

Win10 SDK will still be needed though.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ac68a1f-b5aa-41dc-b336-9982860b4a97%40chromium.org.

[Hayden Livingston]

This is a monumental achievement. You guys should do a blog post or something.

What about all the debug information? Do you have full fidelity?

[Nico Weber]

On Aug 1, 2017 12:47 AM, "Hayden Livingston" <halivi...@gmail.com> wrote:

This is a monumental achievement. You guys should do a blog post or something.

Thanks. Will do eventually, once the change has stuck for a while.

What about all the debug information? Do you have full fidelity?

We think debug info is pretty good. If you're aware of shortcomings, please file a bug.

On Monday, July 31, 2017 at 9:31:18 PM UTC-7, Nico Weber wrote:

On Aug 1, 2017 12:02 AM, "Hayden Livingston" <halivi...@gmail.com> wrote:

Does this mean that LLVM is being used for code-generation of Chromium on Windows? 

Yes.

On Monday, July 31, 2017 at 7:45:45 PM UTC-7, Rong Jie wrote:

FYI, I am getting clang version of Chrome Canary as expected now.

Is Chromium planning to switch from VC++ standard C++ library to libc++ since other platforms already use libc++?

We haven't looked at this yet. MSVC's c++ stdlib is pretty good. We're currently looking at link.exe, since that allows us to do LTO.

Win10 SDK will still be needed though.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4ac68a1f-b5aa-41dc-b336-9982860b4a97%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5e6a90c-f085-4fe6-959a-b955ec97b719%40chromium.org.

[Adrian R.]

problem:

it's not honoring the hint="asan-optout" and is even wiping it during Canary updates. This causes SyzyASAN builds to be installed even when i opted out.

i was pointed in this thread's direction by:

https://productforums.google.com/forum/#!topic/chrome/6iCr3KSlS3A

i have set 

[HKEY_CURRENT_USER\Software\Google\Update\ClientState\{4EA16AC7-FD5A-47C3-875B-DBF4A2008C20}\cohort]

"hint"="asan-optout"

but i  discover that Canary is deleting the hint and installing SyzyASAN 32-bit builds anyway even though i have Canary x64 installed.

Please check what is it doing to the hint during updates.

[Nico Weber]

Thanks for the report, I'll look into it.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/52462bdf-1754-4124-adf3-3d2c0d5065dc%40chromium.org.

[Yoichi Osato]

I have compile failure on clang=false(https://bugs.chromium.org/p/chromium/issues/detail?id=752837). PTAL.

If we had clang=false bots, it could not be merged. Do we have it really?

2017年8月5日(土) 23:21 Nico Weber <tha...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiG5X2Z-wWb_sJ_%2BXEhsLOoSViiOQ8RWeFXeM8aHQLNepw%40mail.gmail.com.

[Yoichi Osato]

I have compile failure on clang=false(https://bugs.chromium.org/p/chromium/issues/detail?id=752837). PTAL.

If we had clang=false bots, it could not be merged. Do we have it really?

2017年8月5日(土) 23:21 Nico Weber <tha...@chromium.org>:

Thanks for the report, I'll look into it.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiG5X2Z-wWb_sJ_%2BXEhsLOoSViiOQ8RWeFXeM8aHQLNepw%40mail.gmail.com.

[Nico Weber]

On Mon, Aug 7, 2017 at 4:42 AM, Yoichi Osato <yoi...@chromium.org> wrote:

I have compile failure on clang=false(https://bugs.chromium.org/p/chromium/issues/detail?id=752837). PTAL.

If we had clang=false bots, it could not be merged. Do we have it really?

We have a cq bot doing MSVC release builds. That build error is component-build only. I commented on the bug.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMGbLiG5X2Z-wWb_sJ_%2BXEhsLOoSViiOQ8RWeFXeM8aHQLNepw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAEV3pmqh8bMjw7h10c93HeUaM-UZVe5Ka1Pdi2NLsi7-A7x9A%40mail.gmail.com.

[Nico Weber]

On Mon, Jul 31, 2017 at 6:43 PM, Nico Weber <tha...@chromium.org> wrote:

On Mon, Jul 31, 2017 at 10:57 AM, Nico Weber <tha...@chromium.org> wrote:

On Mon, Jul 31, 2017 at 2:46 AM, Yoichi Osato <yoi...@chromium.org> wrote:

It makes local debug build about 100 times slower...

This is my local debug gn args:

is_component_build = true

enable_nacl = false

is_clang = false

is_win_fastlink = true

target_cpu = "x86"

is_debug = true

I tested with changing just inserts a empty line in a core/*.cpp,

$ ninja content_shell

With is_clang=false, it just takes 7 seconds.

With turning clang on, it takes 600 seconds!

Thanks for the report! MSVC's link.exe /incremental mode doesn't work well for blink_core because it contains so many inline methods. The good news is that this is fixed in MSVC 2017. Please try:

export GYP_MSVS_VERSION=2017

gclient runhooks

and patch in https://chromium-review.googlesource.com/c/593773/ (which will hopefully land today). This seems to fix this locally for me.

We've investigated in some detail what exactly makes /incremental mode not work in https://crbug.com/560475 , and it looks like we might be able to make this work in 2015 as well (and reduce memory use of link.exe with both 2015 and 2017). But for now, I'd suggest opting in to 2017. Please let me know if this doesn't work for you.

As of #490810, it should just work with MSVC2015 too, in 32-bit builds. (In 64-bit builds, you need MSVC2017, but that's true with both clang-c and Visual Studio's compiler.)

#493264 should also help incremental linking times for blink_core a lot. Yoichi, please give it another try and let us know if things are still slow.

[Yoichi Osato]

It takes over 700 seconds to link. Still much slow:

http://chromium-build-stats.appspot.com/ninja_log/upload/ninja_log.TeKgkWWPQ2EaR_HMCZhwp4DWL993S4JpaaOozPJro8g=.gz/trace.html

2017年8月11日(金) 7:22 Nico Weber <tha...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Nico Weber]

What bot is this from? Or is this from a local build?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoichi Osato]

It's on my local Windows 10.

2017年8月18日(金) 1:16 Nico Weber <tha...@chromium.org>:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Nico Weber]

Was that a full link, or an incremental one? If you touch a few files and rebuild, is it a lot faster? If not, what are your args.gn? (If you aren't, try setting target_cpu="x86")

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Nico Weber]

We've reverted this change last Friday for now, while we investigate symbol information for locals in crash minidumps and a few other assorted debug info issues. I'll send another note when we try again.