The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69ae14a2e56b0ee3642bd5961fe76704848f68e3

commit 69ae14a2e56b0ee3642bd5961fe76704848f68e3
Author: brucedawson <brucedawson@chromium.org>
Date: Thu Mar 23 00:53:38 2017

Split browser.lib to avoid hitting 4 GB limit

In some build configurations on Windows (official build, goma with
symbol_level = 2) browser.lib can grow to about 4 GB which leads to
cryptic build failures. Rather than trying to carefully calculate which
configurations need to split browser.lib it is simpler to just always
split it on Windows. There is no real 'cost' for doing this other than
some potential confusion when developers look at the build internals.

Instead of building obj\chrome\browser\browser.lib the files built will
be obj\chrome\browser\browser_?.lib where '?' is 0-4.

BUG= 701862 

Review-Url: https://codereview.chromium.org/2767693002
Cr-Commit-Position: refs/heads/master@{#458961}

[modify] https://crrev.com/69ae14a2e56b0ee3642bd5961fe76704848f68e3/chrome/browser/BUILD.gn

I just checked a goma build of the chrome target with the browser_lib fix to see if any other .lib files were part of the three comma club:

>dir *.lib /s | find ".lib" | findstr ".*,.*,.*,.*"

The results are:

1,826,760,180 extensions.lib
3,627,398,600 ui.lib

This was in a 32-bit build so ui.lib would be perilously close to the limit in a 64-bit build, but extensions.lib can probably be left alone.

x64 debug component .lib sizes are not actually much different from x86:

1,923,244,094 extensions.lib
3,730,855,510 ui.lib

Note that this is with VS 2017 and enable_nacl = false. Complete settings for 64-bit build was:

is_component_build = true
is_debug = true
target_cpu = "x64"
enable_nacl = false   # Many fewer build steps
treat_warnings_as_errors = false   # Needed until next angle roll
use_goma = true   # Distributed build - don't forget to use -j 500 or similar
symbol_level = 2   # Yes, I want to debug my code
is_win_fastlink = true   # Needed when using goma and symbol_level = 2

set GYP_MSVS_VERSION=2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/07b41129c2000598bba17282207731e8946a4031

commit 07b41129c2000598bba17282207731e8946a4031
Author: brucedawson <brucedawson@chromium.org>
Date: Fri Mar 24 00:21:55 2017

Split ui.lib to avoid hitting 4 GB limit

In some build configurations on Windows (official build, goma with
symbol_level = 2) ui.lib can grow to about 4 GB which leads to cryptic
build failures. Rather than trying to carefully calculate which
configurations need to split ui.lib it is simpler to just always
split it on Windows. There is no real 'cost' for doing this other than
some potential confusion when developers look at the build internals.

Instead of building obj\chrome\browser\ui\ui.lib the files built will
be obj\chrome\browser\ui\ui_?.lib where '?' is 0-4.

This also fixes up some errors in the comments for the previous
change which covered browser.lib.

With this change the next largest .lib file created when building the
'chrome' target is extensions.lib at 1.9 GB, which is a lot of safety
margin (limit is 4 GB for VS 2015 and 2017).

BUG= 701862 

Review-Url: https://codereview.chromium.org/2772583003
Cr-Commit-Position: refs/heads/master@{#459296}

[modify] https://crrev.com/07b41129c2000598bba17282207731e8946a4031/chrome/browser/BUILD.gn
[modify] https://crrev.com/07b41129c2000598bba17282207731e8946a4031/chrome/browser/ui/BUILD.gn