The only thing I remember about this is that I complained about the data download from the wasm fuzzer on https://codereview.chromium.org/2284393003

I'd guess that these being built in prod builds is probably just an accident.

For fuzzers, it feels that there is no legitimate purpose for them being built at all in this environment.

What's about the examples and shells? They are taking much more time in total and to me, it's a pure waste of cycles, both machine and human.

examples and hello world programs are unimportant for sure. blimp is dead now, so we can delete those targets. We use some v8 shell to compile the js tests, but that might go through d8 instead of v8_shell. But that one might be needed.

I don't think we ship content_shell or ash_shell, so I think these can probably go too.

Max, can you please take a look why do these fuzzers being built? As far as I can tell, use_libfuzzer gn variable (which is false by default) is supposed to guard us against that, and it mostly works, but not always, as you can see, and it has a non zero cost.

>examples and hello world programs are unimportant for sure.
good.

> blimp is dead now, so we can delete those targets.
do you mean delete from the repo? I will be happy to do that, can you please file an issue with more details about what needs to be deleted?

> We use some v8 shell to compile the js tests, but that might go through d8 instead of v8_shell. But that one might be needed.
It's relatively cheap (200 seconds and the linker takes just one slot out of 14). Let's keep it.

> I don't think we ship content_shell or ash_shell, so I think these can probably go too.
good

It seems that we should start with fuzzers and blimp first, and then go after the rest of the unneeded stuff.

Sorry for the delayed response (I've been OOO). Yes, I'll take a look into those fuzzers.

Thank you, Max!

fuzzer_test GN template has a bit more complicated condition than 'if use_libfuzzer': https://cs.chromium.org/chromium/src/testing/libfuzzer/fuzzer_test.gni?q=fuzzer_test&sq=package:chromium&l=21

so it's always possible to build fuzzer_test targets on Linux (unless 'disable_libfuzzer=true' set explicitly)

v8_simple.*_fuzzer targets come from here: https://cs.chromium.org/chromium/src/v8/BUILD.gn?q=v8_simple_json_fuzzer&sq=package:chromium&l=2482

CC'ing machenbach@ here to ask if that's really needed for V8.


And cast_remoting_connector_fuzzer probably comes from https://cs.chromium.org/chromium/src/BUILD.gn?q=cast_remoting_connector_fuzzer&sq=package:chromium&l=849

CC'ing miu@ to check if the time for TODO has come :)

Oops, forgot to CC folks. Please take a look at c#8, would appreciate your comments on that :)

Most of the extra V8 targets sneaked in when switching to gn. I think in gyp we needed to add those targets explicitly in order to have them built in chromium. In gn, the "All" target seems to just take everything it finds.

We do not need many of these v8 targets compiled in a chromium context, but we'd still want the targets to exist (in gn) so that we could compile them on-demand.

What we need:
v8_shell - is used on the host during compilation

What we'd like to have:
d8, cctest, unittests

The rest is not required. E.g. no simple_fuzzer targets.

I agree that most of these targets should exist in GN with all flags, but for fuzzers specifically it makes sense to follow the way it's in in src/: only add fuzzers into the tree, if use_libfuzzer=true.

>> only add fuzzers into the tree, if use_libfuzzer=true.
Today it makes sense but in (near?) future I'd like to build all fuzz targets 
in regular build modes as regression tests. 
https://bugs.chromium.org/p/chromium/issues/detail?id=653139
It can be made in yet another special build mode though. 

In this case, it does worth the effort here.

That leaves us with the only viable way to not build unnecessary targets: instead of All, introduce another GN target specifically for the desktop builders.

The simple fuzzer targets in V8 aren't actual libfuzzer targets. They're dummy stand-alone versions of the respective libfuzzer targets without libfuzzer for smoke testing in V8 stand-alone.

We could also introduce another switch that differentiates between V8 stand-alone and V8 in-Chromium, controlled through the build_overrides/v8.gni file.

Then we could simply guard/hide a bunch of targets in V8 stand-alone.

If that's the right way to go, please assign the task to me. CC dpranke to reason about comment 14 as well.

Per kcc@ (#12), excluding fuzzers from GN tree is not the right way to go in the longer term, no action is needed. Thank you for your readiness to help.

As mentioned it would only be an exclusion of V8's dummy targets from the GN tree in Chromium. The GN tree in V8 would still allow to build those targets and run our smoke tests. In Chromium, they have no real meaning.

re: comment #14 - there is already a flag in //build_overrides/build.gni called `build_with_chromium` that you can use.

CL for excluding most of the unneeded v8 targets:
https://codereview.chromium.org/2619743002/

developers need those targets, and the bots should make sure that they build in all configurations.

If the official builders don't need all targets, they shouldn't build them (i.e. don't build "all" but introduce a special target for the official builder that depends on whatever the builder needs).

Also, we should just increase goma capacity so the bots are faster again.

(This is about linking with LTO, so it's independent of goma capacity. I don't disagree with the rest though.)