New issue
Advanced search Search tips

Issue 730511 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

bindings: Check if we should use source_set instead of static_library in blink_{core,modules}_sources()

Project Member Reported by raphael....@intel.com, Jun 7 2017

Issue description

As part of the work on issue 728584, https://chromium-review.googlesource.com/c/525514 has introduced a new target called "bindings_modules_impl" whose purpose is to aggregate generated bindings files that are later consumed by the "modules" target in //third_party/WebKit/Source/modules/BUILD.gn.

"bindings_modules_impl" is declared via the blink_modules_sources() template, which means that on non-component debug builds on Windows it will generate a set of .lib files totaling >4GB in size that are only used to generate the blink_modules library in the end.

In the CL I mentioned above, we discussed some options to alleviate the pain for Windows developers while keeping the blink_modules_sources() as close to its blink_core_sources() counterpart as possible:
- Switching to source_sets in the non-component case when split_count is not set.
- Adding an argument to both templates that forces the use of source_set instead of static_library and using it in bindings_modules_impl.
- Just use source_set directly in bindings_modules_impl.

source_set vs static_library is not such a big issue on Linux (I haven't checked macOS), though it does save around 2GB in disk space in a debug build.

The idea of this bug is to check if we should go with one of the options above, or if the current situation is OK as it is now.
 
Project Member

Comment 1 by sheriffbot@chromium.org, Jun 7 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold
Owner: ----
Status: Available (was: Untriaged)
The main risk would be that changing to a source set would pull in more code/data than a library (since the .obj files are linked proactively instead of on demand). This could be tested easily by measuring the size of some key binaries like chrome.dll and chrome_child.dll in release/non-component builds to see if they change. If the sizes don't increase significantly then a source set should be fine.

Sign in to add a comment