On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth <aba...@webkit.org> wrote:
> On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >> >> 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. > My current approach doesn't result in DumpRenderTree using private interfaces because all binding code will be generated & compiled in WebCoreTestSupport just like internals. On Mon, Jun 4, 2012 at 10:51 AM, Sam Weinig <wei...@apple.com> wrote: > > My objects were to adding V8 support to WebKit2, not WebKitTestRunner. > Okay, that's good to know. Thanks for the clarification. Just to give a bit of history here, the reason I didn't use DumpRenderTree > for writing a test harness for WebKit2 was that there was no real benefit > in me doing so. The requirements of the test harness were quite different > than they were for a test harness for WebKit1, specifically, we had to > split functionality between the UIProcess and injected bundle. In > addition, DumpRenderTree had become a weird hodge-podge of code, where > sharing code between projects seemed to be the exception, rather than the > rule, for instance, I am not sure if the chromium port shares any code in > DumpRenderTree with other ports (I could be wrong there), and since I was > binding to a new API, a fresh start seemed the way to go. All in all, I > feel it has worked quite well, and has allowed better sharing of code > between the Qt, Mac, Gtk and Windows WebKit2 implementations. > > That said, I am not sure the current approach taken in WebKitTestRunner is > fully suited to being merged with DumpRenderTree. It is quite tied to the > idea of having two processes and specifically the WebKit2 API. > Yeah, that's the impression I've got as well. It doesn't seem like we can share much code between DumpRenderTree and WebKitTestRunner other than IDLs. On Mon, Jun 4, 2012 at 11:13 AM, Sam Weinig <wei...@apple.com> wrote: > > I would not object to the IDL files being shared, as long it doesn't > introduce additional mental overhead. Right now, it is pretty simple, and > I would like to keep it that way. > Would you prefer merging directories for DumpRenderTree and WebKitTestRunner or create a new intermediary library/project to share IDLs between the two over moving IDLs to WebCoreTestSupport like I was originally proposing? (See my patches on https://bugs.webkit.org/show_bug.cgi?id=88183 and https://bugs.webkit.org/show_bug.cgi?id=88200) - Ryosuke
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
