Enable linking full chrome on windows GN builds again.

Enable linking full chrome on windows GN builds again.

Now that we have fastbuild and Goma working, it should be safe to
link the full binary again in a GN build on the bots.

TBR=brettw@chromium.org, jam@chromium.org
BUG=354261
Committed: https://crrev.com/3f7de242521430670f79ab9bca1a6f3f0e53d6c2
Cr-Commit-Position: refs/heads/master@{#315140}

[Slava Chigrin, 2015-02-05 09:13:06]

On 2015/02/05 00:30:51, Dirk Pranke wrote:

May I ask, how did you speed up the build process? Is it something internal to
Google? Bug ID seems to be wrong (Issue 354264 is about "Chrome Linux client id
is wrong, again"), so I did not get much information from it...
Thank you!

[Dirk Pranke, 2015-02-05 16:45:58]

On 2015/02/05 09:13:06, Slava Chigrin wrote:
> On 2015/02/05 00:30:51, Dirk Pranke wrote:
> 
> May I ask, how did you speed up the build process? Is it something internal to
> Google? Bug ID seems to be wrong (Issue 354264 is about "Chrome Linux client
id
> is wrong, again"), so I did not get much information from it...
> Thank you!

You're right, the bug id is wrong (should've been 354261), but the right bug id
won't 
answer your question :).

We found three main issues:

1. The GYP builds use fastbuild=1, which disables most debugging information
(the GN equivalent is the "minimal_symbols" config). This makes an enormous
difference in the amount of disk I/O, and probably had a 5x or 10x improvement.

2. The GYP bots use a system called Goma, which is a Google-internal distributed
build system, but Goma wasn't enabled on the GN bots; enabling that probably
had a 2x improvement or better on the try servers.

3. The waterfall bots are old, underpowered machines and there seems to be
something wrong with them that is keeping Goma from working. We're switching to
new VMs now and hopefully that'll fix that issue.

Also, it looks like something has bit-rotted in between Friday and today, so
simply flipping
the switch in this patch isn't enough, but fixing things shouldn't be hard, so
I'll do it 
later today.

[Dirk Pranke, 2015-02-06 01:33:06]

dpranke@chromium.org changed reviewers:
+ jam@chromium.org

[Dirk Pranke, 2015-02-06 01:33:29]

Changing this to a real R=, since the first attempt failed.

John, please approve the PDF changes if they look good to you ...

[brettw, 2015-02-06 23:28:07]

https://codereview.chromium.org/880373008/diff/40001/chrome/BUILD.gn
File chrome/BUILD.gn (right):

https://codereview.chromium.org/880373008/diff/40001/chrome/BUILD.gn#newcode155
chrome/BUILD.gn:155: if (is_linux && enable_plugins) {
I don't understand this change.

[Dirk Pranke, 2015-02-06 23:34:26]

On 2015/02/06 23:28:07, brettw wrote:
> https://codereview.chromium.org/880373008/diff/40001/chrome/BUILD.gn
> File chrome/BUILD.gn (right):
> 
>
https://codereview.chromium.org/880373008/diff/40001/chrome/BUILD.gn#newcode155
> chrome/BUILD.gn:155: if (is_linux && enable_plugins) {
> I don't understand this change.

For some reason the PDF library needs to be statically linked into chrome.exe on
linux (John can say more); however,
linking it in on Windows causes duplicate and missing symbols, and doesn't seem
to be necessary.

We probably shouldn't need it on Linux either, but John needs to look at that.

[Dirk Pranke, 2015-02-06 23:34:30]

The CQ bit was checked by dpranke@chromium.org

[commit-bot: I haz the power, 2015-02-06 23:35:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/880373008/40001

[commit-bot: I haz the power, 2015-02-06 23:53:53]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-02-06 23:55:23]

Patchset 3 (id:??) landed as
https://crrev.com/3f7de242521430670f79ab9bca1a6f3f0e53d6c2
Cr-Commit-Position: refs/heads/master@{#315140}

[jam, 2015-02-07 00:00:31]

lgtm