Split browser.lib to avoid hitting 4 GB limit

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}
Committed: https://chromium.googlesource.com/chromium/src/+/69ae14a2e56b0ee3642bd5961fe76704848f68e3

[brucedawson, 2017-03-21 19:02:30]

brucedawson@chromium.org changed reviewers:
+ brettw@chromium.org

[brucedawson, 2017-03-21 19:02:31]

I wanted your thoughts on this. The problem is that browser.lib grows to ~4 GB
when doing goma builds with symbol_level == 2 because this requires putting
debug information in the .obj files (/Z7) which bloats them considerably.

Getting the exact right conditions is tricky so I'm tempted to just split
browser.lib always on Windows, because I'm not aware of any reason not to.

Thoughts?

[brucedawson, 2017-03-21 19:52:59]

The CQ bit was checked by brucedawson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-21 19:53:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-21 21:56:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-21 21:56:47]

Dry run: This issue passed the CQ dry run.

[brettw, 2017-03-22 21:08:23]

I think the main reason not to split it is just when people are debugging
commands on disk. I'm thinking splitting on Windows all the time might be the
most clear rather than trying to track some complicated conditions.

LGTM

[brucedawson, 2017-03-22 21:42:00]

The CQ bit was checked by brucedawson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-22 21:42:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[brucedawson, 2017-03-22 21:50:53]

Description was changed from

==========
Split browser.lib when using goma to avoid hitting 4 GB limit

Maybe do this on all debug builds? Or always?

Could also use a source_set on debug builds, but that seems more likely
to cause issues by having debug/release builds too different.

BUG=701862
==========

to

==========
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
==========

[brucedawson, 2017-03-22 21:52:27]

Yep, I agree. I updated the CL and finalized the description.

I'm also going to file a feature request with Microsoft for an indirect-library
which would be a .lib file which just contained links to the .obj files. That
would preserve the sometimes desirable behavior of .lib files (only pulling in
.obj files as needed) while avoiding the waste of copying ~4 GB of data to a
.lib file.

[brucedawson, 2017-03-22 22:13:03]

I filed this bug to request an alternative to creating these huge .lib files.
Maybe, some day, ...

https://developercommunity.visualstudio.com/content/problem/34370/vs-linker-n...

[commit-bot: I haz the power, 2017-03-23 00:38:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-23 00:38:10]

Dry run: This issue passed the CQ dry run.

[brucedawson, 2017-03-23 00:46:29]

The CQ bit was checked by brucedawson@chromium.org

[brucedawson, 2017-03-23 00:46:30]

The patchset sent to the CQ was uploaded after l-g-t-m from brettw@chromium.org
Link to the patchset: https://codereview.chromium.org/2767693002/#ps20001
(title: "Split browser.lib always on Windows")

[commit-bot: I haz the power, 2017-03-23 00:47:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-23 00:53:42]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1490229989633120,
"parent_rev": "f59872240739c45017e90aa1be20548177d6df59", "commit_rev":
"69ae14a2e56b0ee3642bd5961fe76704848f68e3"}

[commit-bot: I haz the power, 2017-03-23 00:54:51]

Description was changed from

==========
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
==========

to

==========
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}
Committed:
https://chromium.googlesource.com/chromium/src/+/69ae14a2e56b0ee3642bd5961fe7...
==========

[commit-bot: I haz the power, 2017-03-23 00:54:55]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/69ae14a2e56b0ee3642bd5961fe7...