Bug 208894 – Remove support for WebKitSystemInterface

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Keith Rollin]

This project provided support for facilities that are now handled elsewhere and is no longer needed.

[Radar WebKit Bug Importer]

<rdar://problem/60297590>

[Keith Rollin]

Created attachment 393186 [details]
Patch

[Keith Rollin]

To reviewers, I'm mostly worried about this change:

- # The static runtime is required for AppleWin due to WebKitSystemInterface.lib
- # being compiled with a static runtime.
- set(MSVC_STATIC_RUNTIME ON)

Is it appropriate to remove this settings?

[Brent Fulgham]

Comment on attachment 393186 [details]
Patch

I love it. Delete delete delete! r=me

[Konstantin Tokarev]

(In reply to Keith Rollin from comment #3)
> To reviewers, I'm mostly worried about this change:
> 
> - # The static runtime is required for AppleWin due to
> WebKitSystemInterface.lib
> - # being compiled with a static runtime.
> - set(MSVC_STATIC_RUNTIME ON)
> 
> Is it appropriate to remove this settings?

This depends on how do you build downstream projects and how you distribute their binaries.

1. Runtimes must match, so if you are building WebKit with static runtime (/MT) you should also build application with /MT, if you switch WebKit to shared runtime (/MD) application build settings need to be changed too.

2. If application is built with /MT, it's fully self-contained, while /MD application requires respective msvcrt dlls to be installed.

[Keith Rollin]

On the one hand, it sounds like keeping the setting is good for backward compatibility with WebKit clients. On the other hand, allowing for a /MD style build to a shared runtime configuration would allow for smaller applications.

Who makes the decision on which route we want to take? If I don't hear anything, I'll revert this setting in the name of backward compatibility.

[Keith Rollin]

Created attachment 393674 [details]
Patch

[Per Arne Vollan]

(In reply to Keith Rollin from comment #6)
> On the one hand, it sounds like keeping the setting is good for backward
> compatibility with WebKit clients. On the other hand, allowing for a /MD
> style build to a shared runtime configuration would allow for smaller
> applications.
> 
> Who makes the decision on which route we want to take? If I don't hear
> anything, I'll revert this setting in the name of backward compatibility.

I think maintaining backward compatibility is a good call.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 393674 [details]:

http/tests/security/contentSecurityPolicy/report-status-code-zero-when-using-https.html bug 197297 (author: [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 393674 [details]
Patch

Clearing flags on attachment: 393674

Committed r258520: <https://trac.webkit.org/changeset/258520>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.