This project provided support for facilities that are now handled elsewhere and is no longer needed.
<rdar://problem/60297590>
Created attachment 393186 [details] Patch
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?
Comment on attachment 393186 [details] Patch I love it. Delete delete delete! r=me
(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.
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.
Created attachment 393674 [details] Patch
(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.
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: dbates@webkit.org) The commit-queue is continuing to process your patch.
Comment on attachment 393674 [details] Patch Clearing flags on attachment: 393674 Committed r258520: <https://trac.webkit.org/changeset/258520>
All reviewed patches have been landed. Closing bug.