On 06/04/2012 03:10 AM, Ryosuke Niwa wrote:
On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth <aba...@webkit.org
<mailto:aba...@webkit.org>> wrote:
On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak
<m...@apple.com <mailto:m...@apple.com>> wrote:
On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak
<m...@apple.com <mailto:m...@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.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
