[webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two

Adam Barth abarth at webkit.org
Sun Jun 3 18:01:20 PDT 2012

On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> I am on vacation so I won't be able to review your patch in detail, but
>>> from your description it sounds less appealing to me than the WKTR
>>> approach. It seems like bad layering to me to define the IDL interface in
>>> WebCore for something actually implemented completely outside of WebCore.
>> While you're right that it's somewhat of a layer violation to define the
>> IDL for layoutTestController, WebCoreTestSupport appears to be the most
>> logical place to share files between DumpRenderTree and WebKitTestRunner at
>> the moment unless we're going to create another project/library in Tools.
>> The downside is that they would be using internal WebCore interfaces
>> instead of the public interface as originally intended. I do not think that
>> is a good change, nor does it seem required just to share more code.
> Are you referring to things like JSValueRef? If JS* functions are supposed
> to be tested in DumpRenderTree, then that's a good argument against this
> approach.

JavaScriptCore has a bunch of tests for its API independent of
DumpRenderTree.  I suspect Maciej's point is more about having
DumpRenderTree use public rather than private interfaces so that it's
easier for JavaScriptCore to change its private interfaces.

Have you looked at adding a V8 backend to the code generator that
WebKitTestRunner is using currently?  My guess is that it will be much
simpler than CodeGeneratorV8.pm because WebKitTestRunner doesn't have deal
with all the exciting variety was have in the web platform.
changed in 17 months, so I wouldn't expect an
ongoing maintenance issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120603/61da1c44/attachment.html>

More information about the webkit-dev mailing list