[Webkit-unassigned] [Bug 206350] WebKit/Windows buildbot build ought to ship with Apple Application Support libraries

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 22 12:47:05 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=206350

Don Olmstead <don.olmstead at sony.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |don.olmstead at sony.com

--- Comment #8 from Don Olmstead <don.olmstead at sony.com> ---
So there are a couple different use cases and associated problems.

For WebKit developers they are...

The actual dlls for running the AppleWin port are not distributed outside of iTunes. The .msi version, apparently pre-Windows Store version, can be unzipped in 7Zip so you can get at the actual msi installer. That's more or less hidden knowledge.

The Apple Win port has moved to 64-bit but the library files distributed in the WebKitAuxiliaryLibrary.zip and WebKitSupportLibrary.zip are 32-bit. At least the last time I checked.

At this time anyone outside of Apple cannot build or run the AppleWin port in 64-bit. So this makes it harder for WebKit developers outside of Apple to fix issues with that build. Whether or not that's a big issue I don't know �� since its an Apple decision.

For someone who wants to run a version of WebKit on Windows for whatever reason they are...

Its possibly not clear to someone outside of WebKit developers that there's really no reason to use the AppleWin port. It requires Apple specific libraries, CoreFoundation, CoreGraphics etc, that someone outside of Apple cannot redistribute. It only uses WebKitLegacy so its not a good comparison for someone whose on Windows and might want to see how their site looks in Safari without having a Mac. The features enabled are also not the same so an API in Safari is probably not there in AppleWin.

The only completely open source version of WebKit for Windows that has build artifacts is WinCairo. If someone wanted to embed WebKit in a Windows app WinCairo is what you would use at this time.

Sony is largely supporting WinCairo development due to the shared platform, curl, cairo, etc, and to support our internal developers. At this time we don't have any releases for WinCairo. So the only way to get a Windows build of WebKit is by downloading WinCairo and its requirements.

I'm not entirely sure what Henk's motivations are but those are the problems I see.

For getting the minibrowser working the directions on the site are lacking the fact that the dlls in the bin64 directory need to be copied to the same directory as the MiniBrowser.exe. If it still doesn't work its likely that a MSVC runtime isn't there. We use Visual Studio 2019 so that'll need to be installed.

If the MiniBrowser.exe runs successfully then it'll display https://webkit.org. For further debugging https://github.com/lucasg/Dependencies can be used which will figure out what dlls are not loading.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200122/370a530a/attachment-0001.htm>


More information about the webkit-unassigned mailing list