Running `time caffeinate ninja -C out/gn/ obj/v8/v8_base/source-position.o` takes twice as long for empty builds in static library builds compared to component builds (on my laptop, 1.2s vs 0.6s -- the latter is fast enough, the former isn't).

`find out/gn/ -name '*.ninja' -print0 | xargs -0 wc -c | sort -n` says that gn generates 30MB of ninja files for component builds, but 50MB for static library builds.

Looking at the generated ninja files, this is mostly due to source_set()s having an O(n^2) effect on output file size: every test target depending on chrome lists all object files belonging to chrome on its link line.

One approach to fix this could be to give source_sets a "link" step that just produces a txt file listing all the .o files part of that source_set, and then pass that to the linker via @ or -filelist (on mac) -- that way, the list of object files of chrome are listed just once and not repeated for every target depending on chrome.

This is not a problem in gyp because that uses static_libraries instead of source_sets.