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}
diff --git a/chrome/browser/BUILD.gn b/chrome/browser/BUILD.gn
index 56034ef..587c0fa 100644
--- a/chrome/browser/BUILD.gn
+++ b/chrome/browser/BUILD.gn
@@ -56,9 +56,9 @@
# require many files from it. This makes linking more efficient.
split_static_library("browser") {
# Split into multiple static libraries on Windows builds. We have hit size
- # on Windows official builds and on goma builds symbol_level = 2 is selected.
- # Always splitting on Windows builds is simpler than trying to perfectly
- # calculate the scenarios where it is required.
+ # limits on Windows official builds and on goma builds when symbol_level = 2
+ # is selected. Always splitting on Windows builds is simpler than trying to
+ # perfectly calculate the scenarios where it is required.
if (is_win) {
split_count = 5
} else {
