Bug 90262 – [Qt][WTR] Get rid of using DumpRenderTreeSupportQt

• Status: RESOLVED
• Resolution: INVALID
• Component: Tools / Tests

[Balazs Kelemen]

The only reason why we use it in some place is the v8 support. Now that we are over with it we can remove these.

[Balazs Kelemen]

Created attachment 150134 [details]
Patch

[Balazs Kelemen]

Comment on attachment 150134 [details]
Patch

Clearing flags on attachment: 150134

Committed r121550: <http://trac.webkit.org/changeset/121550>

[Balazs Kelemen]

All reviewed patches have been landed.  Closing bug.

[Balazs Kelemen]

Reverted in r121788. Need to fix some issues of the Qt build system before relanding this.

[Balazs Kelemen]

*** Bug 90346 has been marked as a duplicate of this bug. ***

[Balazs Kelemen]

Created attachment 154410 [details]
Patch

[Early Warning System Bot]

Comment on attachment 154410 [details]
Patch

Attachment 154410 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/13342356

[Simon Hausmann]

Comment on attachment 154410 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=154410&action=review

I think the patch is good, I like this approach. But it appears to break the Gtk build, the EWS failure seems valid.

> Source/WebCore/ChangeLog:3
> +        [Qt][WTR] Get rid of using DumpRenderTreeSupportQt

I think the title is a bit generic, what about renaming it to "Get rid of DumpRenderTreeSupportQt::injectInternals wrapper"?

[Balazs Kelemen]

Created attachment 155747 [details]
Patch

[Build Bot]

Comment on attachment 155747 [details]
Patch

Attachment 155747 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13400755

[Build Bot]

Comment on attachment 155747 [details]
Patch

Attachment 155747 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13393977

[Build Bot]

Comment on attachment 155747 [details]
Patch

Attachment 155747 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13417118

[Balazs Kelemen]

Adding WEBCORE_TESTING to WebCoreTestSupport::injectInternalsObject and WebCoreTestSupport::resetInternalsObject breaks the win build. It needs the symbol "__declspec(dllimport) void __cdecl WebCoreTestSupport::injectInternalsObject(struct OpaqueJSContext const *)" in DRT but it doesn't find it. It seems strange to me because dllimport should be the right here to do from DRT. Idea?

[Hajime Morrita]

(In reply to comment #13)
> Adding WEBCORE_TESTING to WebCoreTestSupport::injectInternalsObject and WebCoreTestSupport::resetInternalsObject breaks the win build. It needs the symbol "__declspec(dllimport) void __cdecl WebCoreTestSupport::injectInternalsObject(struct OpaqueJSContext const *)" in DRT but it doesn't find it. It seems strange to me because dllimport should be the right here to do from DRT. Idea?

WEBCORE_TESTING isn't ready yet. I'm sorry for the inconvenience,

[Balazs Kelemen]

(In reply to comment #14)
> (In reply to comment #13)
> > Adding WEBCORE_TESTING to WebCoreTestSupport::injectInternalsObject and WebCoreTestSupport::resetInternalsObject breaks the win build. It needs the symbol "__declspec(dllimport) void __cdecl WebCoreTestSupport::injectInternalsObject(struct OpaqueJSContext const *)" in DRT but it doesn't find it. It seems strange to me because dllimport should be the right here to do from DRT. Idea?
> 
> WEBCORE_TESTING isn't ready yet. I'm sorry for the inconvenience,

I'm a bit confused how to proceed with this. I don't want to add a new platform specific define because WEBCORE_TESTING is supposed to serve for this Could you describe what is missing and how could those symbols note become exported?

[Balazs Kelemen]

I could not take care about this in the foreseeable future so feel free to pick it.