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

[Balazs Kelemen]

On 06/04/2012 03:10 AM, Ryosuke Niwa wrote:
> On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth <abarth at webkit.org 
> <mailto:abarth at webkit.org>> wrote:
>
>     On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa <rniwa at webkit.org
>     <mailto:rniwa at webkit.org>> wrote:
>
>         On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak
>         <mjs at apple.com <mailto:mjs at apple.com>> wrote:
>
>             On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa <rniwa at webkit.org
>             <mailto:rniwa at webkit.org>> wrote:
>>             On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak
>>             <mjs at apple.com <mailto: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.
>     http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/Bindings/CodeGeneratorTestRunner.pm
>     hasn't changed in 17 months, so I wouldn't expect an
>     ongoing maintenance issue.
>
>
> Yes. But there was a recent discussion about supporting V8 in 
> WebKitTestRunner where Sam objected to it citing that doing so will 
> clutter the WTR's codebase. I have no problem with creating a V8 
> backend if Sam doesn't mind introducing V8 equivalent there.
>
> However, the real difficulty is in sharing files between 
> WebKitTestRunner and DumpRenderTree, and modifying 11? build 
> configurations we have for DumpRenderTree.
>
> - Ryosuke
>

I think you refer to the discussion started by me. To make it clear, it 
was about whether can we support v8 in WebKit2, not (just) 
WebKitTestRunner. The solution of mine - wrapping v8 with the jsc api 
for WTR - would make it unnecessary to change anything on WTR. On the 
other hand, using generated bindings in WTR and WebKit2 could also be a 
way to keep the mantainance overhead of supporting v8 low.


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