Bug 67777
Summary: | new-run-webkit-tests does not support qt-arm results | ||
---|---|---|---|
Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | abrhm, dpranke, eric, kadam, ossy, rgabor, zarvai |
Priority: | P3 | Keywords: | NRWT |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | 120207 | ||
Bug Blocks: | 88680, 89880 |
Csaba Osztrogonác
.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
Do we have a qt-arm port? Does it have results?
Eric Seidel (no email)
I guess I'll assume that's a no? Please re-open if this is an issue.
Csaba Osztrogonác
Yes, we have.
Csaba Osztrogonác
And it has results and Skipped list too in LayoutTests/platform/qt-arm.
Eric Seidel (no email)
OK. Looks like qt-arm is just supposed to fall back to qt:
http://trac.webkit.org/browser/trunk/Tools/Scripts/old-run-webkit-tests#L2186
} elsif ($platform =~ /^qt-/) {
push @platforms, $platform;
push @platforms, "qt";
Eric Seidel (no email)
It would be possible to hack this by adding he following to the end of Qt.__init__ in ports/qt.py:
# FIXME: This is a total hack for the qt-arm port.
if 'arm' in platform.machine():
self._name = 'qt-arm'
But what really should happen is we should come up with some consisten vision for how fallback should work across Qt. Right now qt-arm is a one-off (I don't believe it wishes to participate in normal version fallback, right?) and all of Qt fallback is different from Mac/Win which fall back from most-specific version to newer versions then to the base directory. Qt, my understanding is falls back just to most-specific version then the base directory.
Eric Seidel (no email)
I plan to leave qt-arm for someone in Qt to handle. It's easy to hack-in as noted above, but I would advise understanding how we want fallback to work for Qt before adding arm support to NRWT.
Eric Seidel (no email)
Moving this off of the "move all bots" bug, as I don't plan to do this before closing that bug and making NRWT default for all other ports. qt-arm will remain on an explicit black-list of unsupported ports for now.
Csaba Osztrogonác
We should add qt-arm to baseline search paths, it is quite simple.
And we should find the python way for ARM architecture detection somehow.
Csaba Osztrogonác
bug120207 will solve this problem too.
*** This bug has been marked as a duplicate of bug 120207 ***