Reduce chrome.exe .text size by 50 KB with static_library

Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274
Committed: https://crrev.com/fe9b427bc2c5c840906daef07c6dd6789cfc6447
Cr-Commit-Position: refs/heads/master@{#405671}

[brucedawson, 2016-07-13 17:01:17]

Description was changed from

==========
chrome.exe gn size optimizations, in five parts

crashpad, various

mojo/public/cpp/bindings: No difference in binary size

breakpad:breakpad_handle: no difference

components/metrics: No difference in binary size

components/variations: No difference in binary size

BUG=624274
==========

to

==========
chrome.exe gn size optimizations, in five parts

crashpad, various

mojo/public/cpp/bindings: No difference in binary size

breakpad:breakpad_handle: no difference

components/metrics: No difference in binary size

components/variations: 50 KB difference in binary size

BUG=624274
==========

[brucedawson, 2016-07-14 20:35:44]

Description was changed from

==========
chrome.exe gn size optimizations, in five parts

crashpad, various

mojo/public/cpp/bindings: No difference in binary size

breakpad:breakpad_handle: no difference

components/metrics: No difference in binary size

components/variations: 50 KB difference in binary size

BUG=624274
==========

to

==========
Reduce chrome.exe .text size by 50 KB with static_library

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

Most of the gain came from the change to components/variations, but the
other 

This change also reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.


BUG=624274
==========

[brucedawson, 2016-07-14 20:39:21]

Description was changed from

==========
Reduce chrome.exe .text size by 50 KB with static_library

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

Most of the gain came from the change to components/variations, but the
other 

This change also reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.


BUG=624274
==========

to

==========
Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274
==========

[brucedawson, 2016-07-14 20:39:21]

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

[brucedawson, 2016-07-14 20:40:19]

PTAL. This was created by focusing on chrome.exe and it also improves build
times overall.

Note that three of the changed lines are adding comments just say that this
source_set can't be changed to a static_library.

Thoughts?

[brettw, 2016-07-14 21:38:38]

LGTM.

I also converted some other third_party stuff here
https://codereview.chromium.org/2152033002
(I removed collisions with your patch)

[brucedawson, 2016-07-15 00:39:50]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2016-07-15 00:40:22]

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, 2016-07-15 02:03:03]

Description was changed from

==========
Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274
==========

to

==========
Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274
==========

[commit-bot: I haz the power, 2016-07-15 02:03:05]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-07-15 02:03:07]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-15 02:04:58]

Description was changed from

==========
Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274
==========

to

==========
Reduce chrome.exe .text size by 50 KB with static_library

Also improves build times.

chrome.exe's .text (code) section in gn builds is about 55 KB larger
than in gyp builds (32-bit official). This is largely or completely
because of the use of source sets. The gn build links with about 320
.obj files whereas the gyp build links with ten. The linker pulls in
all of those .obj files and then fails to do a perfect job of discarding
the unused code and data.

This change gets rid of ~50 KB of this discrepancy by changing several
build targets from source_set to static_library and reducing the number
of .obj files to be linked to 72.

The size gain came from the change to components/variations, but the
other changes help to ensure that the size gain sticks, and help with
build speeds.

This change reduces the build times for relinking the affected
binaries (mostly chrome.dll and chrome_child.dll) in an official build
about 4-7%.

Some source_set targets could not be changed. These were annotated as
such to avoid wasting time on them in the future.

BUG=624274

Committed: https://crrev.com/fe9b427bc2c5c840906daef07c6dd6789cfc6447
Cr-Commit-Position: refs/heads/master@{#405671}
==========

[commit-bot: I haz the power, 2016-07-15 02:04:59]

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

[Nico, 2016-07-15 14:08:06]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2016-07-15 14:08:07]

https://codereview.chromium.org/2149483002/diff/100001/third_party/libpng/BUI...
File third_party/libpng/BUILD.gn (right):

https://codereview.chromium.org/2149483002/diff/100001/third_party/libpng/BUI...
third_party/libpng/BUILD.gn:36: # Cannot be a static_library in component builds
fwiw in gyp it's a component on windows and a static library elsewhere

[brucedawson, 2016-07-15 18:08:54]

https://codereview.chromium.org/2149483002/diff/100001/third_party/libpng/BUI...
File third_party/libpng/BUILD.gn (right):

https://codereview.chromium.org/2149483002/diff/100001/third_party/libpng/BUI...
third_party/libpng/BUILD.gn:36: # Cannot be a static_library in component builds
On 2016/07/15 14:08:07, Nico wrote:
> fwiw in gyp it's a component on windows and a static library elsewhere

Yep, and you can't pull a static_library with exports into a DLL so on Windows
we would need to make it a source_set in component builds and a static_library
otherwise. I wasn't sure if it was worth the extra complexity for the 17 .obj
files that this represents.