cc skobes@, who made run-webkit-tests write output to out/.

> 1. third_party/WebKit/Tools/Scripts/run-webkit-tests seems to expect that
> the output directories are out/Release or out/Debug, but GN lets you specify
> any output directory. There should be a new flag that lets you specify any
> output directory.

Pass --build-directory=X --target=Y for a build directory of X/Y (e.g., out.foo/bar).

> 2. The blink_tests GN target doesn't build dump_syms and minidump_stackwalk,
> both of which are required to call run-webkit-tests.

What platform was this on? Looks like they should be built everywhere except
maybe Win, but it doesn't loook like GYP builds them on Win either? Are 
they actually needed or used) on Win?

For #2, blink_test do build those targets:
https://code.google.com/p/chromium/codesearch#chromium/src/BUILD.gn&q=build.gn%20blink_tests&sq=package:chromium&l=811

Agree it'd be a good idea to have the location of the build outputs be configurable. Most scripts use --output-directory or --chromium-output-directory. The main bug for this is  bug #573345 

For #1, thanks!

For #2, this was on Linux with a Chrome OS target. I built blink_tests and run-webkit-tests complained that it couldn't find dump_syms or minidump_stackwalk. I then told it to build dump_syms and minidump_stackwalk too and then it worked.

It appeared they were already built and just needed to be copied to the right location?

I'll see if I can repro that.

Ah. Running the layout tests on ChromeOS isn't something people really do (we don't do it on the bots, and there aren't baselines for it), so I'm not surprised this part is broken.

That said, there's no reason we can't make it at least kinda work.

I don't think this needs to block dropping GYP support ...

dmazzoni@, have you tried to build blink_tests for Chrome OS recently? Do you know what's necessary to make this work?

Here's an example of one thing that's broken:

> gn args gn_out/cros
is_component_build = true
is_debug = false
use_goma = true
goma_dir = "/ssd1tb/goma"
target_os = "chromeos"

> gn_out/cros/content_shell --run-layout-test third_party/WebKit/LayoutTests/accessibility/name-calc-inputs.html

...successfully runs the test, then crashes:

Received signal 11 SEGV_MAPERR ffffc2bb270207e2
#0 0x7f3a9ae508e7 base::debug::StackTrace::StackTrace()
#1 0x7f3a9ae5045f base::debug::(anonymous namespace)::StackDumpSignalHandler()#2 0x7f3a9c7f0330 <unknown>
#3 0x7f3a9ba89a80 content::RenderWidgetHostViewAura::~RenderWidgetHostViewAura()
#4 0x7f3a9ba89db9 content::RenderWidgetHostViewAura::~RenderWidgetHostViewAura()
#5 0x7f3a995b0fd1 aura::Window::~Window()

BTW, what would be the harm in running all of the cross-platform layout tests on Chrome OS? A huge percentage of the tests have cross-platform expectations and don't need platform-specific ones.

It just seems like we're missing some really important test coverage. Not because Chrome OS should behave differently, but because it really is building a slightly different stack, which could affect the web platform.

That's true. There would be no harm in running layout tests on Chrome OS, but that does imply setting up builders to run the tests, and maintaining Chrome OS as another supported platform. More supported platforms -> more coverage, but also more maintenance.

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