bindings: Check if we should use source_set instead of static_library in blink_{core,modules}_sources() |
||
Issue descriptionAs 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.
,
Jun 7 2018
,
Jun 7 2018
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 |
||
Comment 1 by sheriffbot@chromium.org
, Jun 7 2018Status: Untriaged (was: Available)