Could the Win32 target be added back, please? I'd like to help with that version to make it compile and run, using WebKit2 (I know WebKit1 is gone in 2.6.x, which is the reason for this bug report too). The cmake currently claims to me that either x11 or wayland target should be enabled, but I'd like to build under the Win32, using msys/mingw. This could be done with fixes from bug #133028 (and its tree of dependencies) as a starter.
If I recall correctly, the only "problem" would be the interprocess communication, but for that can be used D-Bus, just like on Linux, especially when it is patched with https://bugs.freedesktop.org/show_bug.cgi?id=83539 .
Thus there might not be any major issues blocking the build, I guess.
If you'd prefer to add here a patch for me for testing (and eventually to be extended by me), then I'm all for it.
It is a WebKitGTK+ specific bug, isn't it?
Supporting WebKit2 on Windows is much more complex task. As far as I know,
only Apple and Qt had working WebKit2 port on Windows, WebKitGTK+ hadn't
support WebKit2 on Windows ever. And Apple dropped their WK2 Windows port
21 months ago - http://trac.webkit.org/changeset/139003, QtWebKit was removed
from trunk circa a year ago. So there isn't any port in WebKit trunk which
supports WebKit2 on Windows now.
We don't use DBus for the IPC in WebKit, we use the internal IPC mechanism based on socketpair, stream sockets and shared memory mainly. Those are the things that would need to be implemented in Windows (among other things). See:
Oh, I see. I thought WebKit is also using D-bus, but it might be just an implementation detail on the epiphany side when communicating between the web extension and the "client".
I'll check those files, thanks for the pointers. It would be extremely helpful to have something similar as is the win32 target in 2.4.x. I'm not quite sure how to do that in the cmake world, while the 2.4.x tarball releases had this all prebuilt with the autotools stuff. I could try to make WebKit2 work in 2.4.x, but it feels counter-productive due to all the changes in trunk and 2.6.x.
(In reply to comment #4)
> Oh, I see. I thought WebKit is also using D-bus, but it might be just an implementation detail on the epiphany side when communicating between the web extension and the "client".
Yes, that's something done in the application side for the communication between web process extensions and the UI process.
> I'll check those files, thanks for the pointers.
You could take a look at the revision when the win port was removed from WebKit2, it had implementations for those files, see:
> It would be extremely helpful to have something similar as is the win32 target in 2.4.x. I'm not quite sure how to do that in the cmake world, while the 2.4.x tarball releases had this all prebuilt with the autotools stuff. I could try to make WebKit2 work in 2.4.x, but it feels counter-productive due to all the changes in trunk and 2.6.x.
I have no idea how to do that in cmake either, but I agree it would be better to work on that in trunk.
Nice, thanks for the pointers. As this will be a long run, I do not expect this to be quick, if you wish, then feel free to close this bug report and I reopen it when/if I'll have anything workable. Thanks again for the guide where to look.
Created attachment 250085 [details]
Early attempt to re-add win32 target to GTK cmake
I started to add some checks for WIN32 in cmake, it is not finished yet
Created attachment 261992 [details]
cmake mingw for 2.10.0
Some updates for webkitgtk 2.10.0 (may need to see Pawel's patch too)
Created attachment 262552 [details]
Updated build patch
maybe useful to fix build issues, my binary segfaulted though.
Hmm, I didn't try to build WebKit2 under Windows for a long time. Your patch seems quite short, with compare of the changes I have in my outdated checkout. I also see that some parts clash with the opened bug reports from the "Depends on" section, both of bug #137974 and bug #143884. The "Prefer GTK+ over Windows" patch is also outdated there, I made more such changes locally couple months ago. I guess it's due to using different configure (cmake) options.