Both GTK3 and GTK4 can be installed in parallel in the same system. We would like to make it possible to build WebKitGTK targeting either version and have builds for both to be parallel-installable as well. We need a way of telling CMake which version to pick when configuring a build.
Created attachment 395737 [details] Patch
Comment on attachment 395737 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=395737&action=review LGTM. Since this is important, Carlos will want to review it before it lands. > Source/cmake/OptionsGTK.cmake:10 > + set(WEBKITGTK_API_VERSION 5.0) Maybe we could use API version 0.0 and call it libwebkit2gtk4-0.0? (And eventually bump to 1.0 once it's ready to become stable?) That might be less confusing than expecting people to know libwebkit2gtk-5.0 in the GTK 4 version? (Yes, I know it doesn't match GTK 3's libwebkit2gtk-4.0, but we can't ever change that....) That might also be a nice nudge to distros on how to standardize the package naming. Distros are currently split between webkit2gtk and webkit2gtk3 (and previously, webkitgtk3 and webkitgtk4, amazingly confusing!). I think in Fedora/RHEL we will call this webkit2gtk4, so.... > Source/cmake/OptionsGTK.cmake:13 > + set(GTK_MINIMUM_VERSION 3.98.2) > + CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(WEBKIT 83 0 0) > + CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(JAVASCRIPTCORE 36 0 0) Doesn't matter, but I would reset the ABI versions to 0 0 0, since the API version is being bumped. Consider that even the GTK 3 version might eventually need to break ABI, even if the current goal is to never do that. (E.g. we are dangerously low on padding in the WebKitWebView class struct, and I think ABI break is nicer than just not adding a vfunc for new signals. An ABI break every 5-10 years is not horrible; it's the *API* breaks that are hard for distros.)
Comment on attachment 395737 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=395737&action=review I think we need more changes for the API bump. We need to add new doc files, pkg-config, etc. Do you plan to do that in follow up patches? >> Source/cmake/OptionsGTK.cmake:10 >> + set(WEBKITGTK_API_VERSION 5.0) > > Maybe we could use API version 0.0 and call it libwebkit2gtk4-0.0? (And eventually bump to 1.0 once it's ready to become stable?) That might be less confusing than expecting people to know libwebkit2gtk-5.0 in the GTK 4 version? (Yes, I know it doesn't match GTK 3's libwebkit2gtk-4.0, but we can't ever change that....) > > That might also be a nice nudge to distros on how to standardize the package naming. Distros are currently split between webkit2gtk and webkit2gtk3 (and previously, webkitgtk3 and webkitgtk4, amazingly confusing!). I think in Fedora/RHEL we will call this webkit2gtk4, so.... I think that complicates things, since bumping the ABI is not just using a new version of WEBKITGTK_API_VERSION. If we want to do it, maybe we can also remove 2, since webkit2 is the only webkit layer nowadays. >> Source/cmake/OptionsGTK.cmake:13 >> + CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(JAVASCRIPTCORE 36 0 0) > > Doesn't matter, but I would reset the ABI versions to 0 0 0, since the API version is being bumped. > > Consider that even the GTK 3 version might eventually need to break ABI, even if the current goal is to never do that. (E.g. we are dangerously low on padding in the WebKitWebView class struct, and I think ABI break is nicer than just not adding a vfunc for new signals. An ABI break every 5-10 years is not horrible; it's the *API* breaks that are hard for distros.) I agree, it's actually a new library, so we don't need to follow the numbers of the other library.
(In reply to Carlos Garcia Campos from comment #3) > Comment on attachment 395737 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=395737&action=review > > I think we need more changes for the API bump. We need to add new doc files, > pkg-config, etc. Do you plan to do that in follow up patches? Yes, there will be follow-ups. The plan is to get to the point where we can build against GTK4 first, so we can progressively write the code that has to be different inside USE(GTK4) conditionals and/or stub them out. Once we have done the minimum amount of work needed to get a WebKitWebView showing some content, we can look into ironing out reference documentation, installation, and so on. As a reminder: bug #210100 is a meta-bug to track the overall progress. > >> Source/cmake/OptionsGTK.cmake:10 > >> + set(WEBKITGTK_API_VERSION 5.0) > > > > Maybe we could use API version 0.0 and call it libwebkit2gtk4-0.0? (And eventually bump to 1.0 once it's ready to become stable?) That might be less confusing than expecting people to know libwebkit2gtk-5.0 in the GTK 4 version? (Yes, I know it doesn't match GTK 3's libwebkit2gtk-4.0, but we can't ever change that....) > > > > That might also be a nice nudge to distros on how to standardize the package naming. Distros are currently split between webkit2gtk and webkit2gtk3 (and previously, webkitgtk3 and webkitgtk4, amazingly confusing!). I think in Fedora/RHEL we will call this webkit2gtk4, so.... > > I think that complicates things, since bumping the ABI is not just using a > new version of WEBKITGTK_API_VERSION. If we want to do it, maybe we can also > remove 2, since webkit2 is the only webkit layer nowadays. GTK4 went with simplifying the installed library name. It is using “libgtk-4” as basename. I think we could do the same and use “libwebkitgtk-4”. This way we get to remove the “2” (as there will be no WebKit1), it will encourage distributions to use “webkitgtk4” or “webkitgtk-4” as package name, and it will be clear which GTK version the library uses. WDYT? > >> Source/cmake/OptionsGTK.cmake:13 > >> + CALCULATE_LIBRARY_VERSIONS_FROM_LIBTOOL_TRIPLE(JAVASCRIPTCORE 36 0 0) > > > > Doesn't matter, but I would reset the ABI versions to 0 0 0, since the API version is being bumped. > > > > Consider that even the GTK 3 version might eventually need to break ABI, even if the current goal is to never do that. (E.g. we are dangerously low on padding in the WebKitWebView class struct, and I think ABI break is nicer than just not adding a vfunc for new signals. An ABI break every 5-10 years is not horrible; it's the *API* breaks that are hard for distros.) > > I agree, it's actually a new library, so we don't need to follow the numbers > of the other library. Good point, let's reset the libtool triplets to be (0 0 0) for both libraries.
(In reply to Carlos Garcia Campos from comment #3) > I think that complicates things, since bumping the ABI is not just using a > new version of WEBKITGTK_API_VERSION. If we want to do it, maybe we can also > remove 2, since webkit2 is the only webkit layer nowadays. I thought about whether to suggest this. +1 to removing the 2. (In reply to Adrian Perez from comment #4) > GTK4 went with simplifying the installed library name. It is using “libgtk-4” > as basename. I think we could do the same and use “libwebkitgtk-4”. This way > we get to remove the “2” (as there will be no WebKit1), it will encourage > distributions to use “webkitgtk4” or “webkitgtk-4” as package name, and it > will be clear which GTK version the library uses. > > WDYT? I'm OK with that. There, the API version is "4". Makes sense. In the unlikely event that we do need to break API in the future after the first stable release, we can always just bump it to 4.1 or something, so it would still be possible to parallel-install with the old version if needed. And before the first stable release, it should be fine to just bump soname whenever we change things. So the final result would be: libwebkitgtk-4.so. I like it. Sadly, the potential for confusion with libwebkit2gtk-4.0.so (GTK 3) is very high. Maybe libwebkitgtk4.so would be a bit less confusing, but that name doesn't look quite as nice to me. Oh well. Whatever you pick will be fine.
I think that from the distribution point of view any solution is fine as long as the library name, pkg-config .pc file, etc. are different. My understanding is that: - There will probably be an API break. - As a result, there will be a different set of header files. - The same javascriptcore build can in principle be shared between both versions of WebKitGTK (this is not essential). So in the end this is going to be similar to the previous change when we switched to the WebKit 2 API. If we want to take the chance to remove the '2' from the library name, that's fine with me (libwebkitgtk-X.X or whatever). I don't have a strong opinion about the name itself. For reference, there was a time when we had GTK2 and GTK3 builds of the same WebKitGTK sources. This is what we had in configure.ac: case "$with_gtk" in 2.0) GTK_REQUIRED_VERSION=$GTK2_REQUIRED_VERSION GTK_API_VERSION=2.0 WEBKITGTK_API_MAJOR_VERSION=1 WEBKITGTK_API_MINOR_VERSION=0 WEBKITGTK_API_VERSION=1.0 WEBKITGTK_PC_NAME=webkit GAIL_PC_NAME=gail GAIL_REQUIRED_VERSION=$GAIL2_REQUIRED_VERSION ;; 3.0) GTK_REQUIRED_VERSION=$GTK3_REQUIRED_VERSION GTK_API_VERSION=3.0 WEBKITGTK_API_MAJOR_VERSION=3 WEBKITGTK_API_MINOR_VERSION=0 WEBKITGTK_API_VERSION=3.0 WEBKITGTK_PC_NAME=webkitgtk GAIL_PC_NAME=gail-3.0 GAIL_REQUIRED_VERSION=$GAIL3_REQUIRED_VERSION ;; esac So this would produce libwebkitgtk-1.0.so.* for the GTK2 build and libwebkitgtk-3.0.so.* for the GTK3 build (even though the actual C API was the same if I'm not wrong). In Debian we'll probably have to keep the webkit2gtk name in the source package. No big deal, it's actually convenient to keep using the same source package (the naming is not so important), but we can only do it as long as 1) We keep producing both the gtk3 and gtk4 builds from the exact same sources. 2) The gtk3 build remains API and ABI compatible with the existing versions (e.g. 2.28.0) We want to avoid a situation where we are not maintaining the GTK3 version anymore but we still have apps using it. Do you expect that we'll have problems keeping both GTK versions for as long as the overall GTK3 -> GTK4 transition lasts?
(In reply to Alberto Garcia from comment #6) > I think that from the distribution point of view any solution is fine > as long as the library name, pkg-config .pc file, etc. are different. And package version, I guess, since we are bumping ABI version, it would be weird to use 2.30 as the version number (or 2.32), I guess it should be 3.0 for the new API. > My understanding is that: > > - There will probably be an API break. That's for sure, we are using GTK APIs in our public API that no longer exist in GTK4. The idea is to take advantage fo the API break to remove all deprecated APIs, revise some existing ones like the load events, give more padding to public class structs, etc. > - As a result, there will be a different set of header files. Right, it's like a new API in the end, like the switch to WebKit2, but with fewer changes and in the same codebase. > - The same javascriptcore build can in principle be shared between > both versions of WebKitGTK (this is not essential). Right, and WebDriver, since it doesn't use GTK at all. > So in the end this is going to be similar to the previous change when we > switched to the WebKit 2 API. Yes, The main difference from the code maintenance point of view is that we had different code paths WebKit and WebKit2 folders in the source tree, making everything easier. > If we want to take the chance to remove the '2' from the library name, > that's fine with me (libwebkitgtk-X.X or whatever). But only for the library created when compiling with gtk4, the gtk3 one would remain the same, API/ABI backwards compatible. > I don't have a strong opinion about the name itself. For reference, > there was a time when we had GTK2 and GTK3 builds of the same > WebKitGTK sources. This is what we had in configure.ac: > > case "$with_gtk" in > 2.0) GTK_REQUIRED_VERSION=$GTK2_REQUIRED_VERSION > GTK_API_VERSION=2.0 > WEBKITGTK_API_MAJOR_VERSION=1 > WEBKITGTK_API_MINOR_VERSION=0 > WEBKITGTK_API_VERSION=1.0 > WEBKITGTK_PC_NAME=webkit > GAIL_PC_NAME=gail > GAIL_REQUIRED_VERSION=$GAIL2_REQUIRED_VERSION > ;; > 3.0) GTK_REQUIRED_VERSION=$GTK3_REQUIRED_VERSION > GTK_API_VERSION=3.0 > WEBKITGTK_API_MAJOR_VERSION=3 > WEBKITGTK_API_MINOR_VERSION=0 > WEBKITGTK_API_VERSION=3.0 > WEBKITGTK_PC_NAME=webkitgtk > GAIL_PC_NAME=gail-3.0 > GAIL_REQUIRED_VERSION=$GAIL3_REQUIRED_VERSION > ;; > esac > > So this would produce libwebkitgtk-1.0.so.* for the GTK2 build and > libwebkitgtk-3.0.so.* for the GTK3 build (even though the actual C API > was the same if I'm not wrong). Exactly, that's a key point. In this case we supported gtk2 and gtk3 for the very same WebKit1 API. We decided not to support gtk2 in the WebKit2 API from the very beginning because it was going to be a huge pain. > In Debian we'll probably have to keep the webkit2gtk name in the > source package. No big deal, it's actually convenient to keep using > the same source package (the naming is not so important), but we can > only do it as long as > > 1) We keep producing both the gtk3 and gtk4 builds from the exact > same sources. I'm not sure anymore about this, I'm starting to think that using a separate branch for gtk3 (like gtk itself did) is the way to go. > 2) The gtk3 build remains API and ABI compatible with the existing > versions (e.g. 2.28.0) Yes, that's for sure. > We want to avoid a situation where we are not maintaining the GTK3 > version anymore but we still have apps using it. Do you expect that > we'll have problems keeping both GTK versions for as long as the > overall GTK3 -> GTK4 transition lasts? We will keep maintaining the gtk3 support as long as gtk3 is supported.
(In reply to Carlos Garcia Campos from comment #7) > > I think that from the distribution point of view any solution is > > fine as long as the library name, pkg-config .pc file, etc. are > > different. > And package version, I guess, since we are bumping ABI version, it > would be weird to use 2.30 as the version number (or 2.32), I guess > it should be 3.0 for the new API. Ok, no problem. > > 1) We keep producing both the gtk3 and gtk4 builds from the > > exact same sources. > I'm not sure anymore about this, I'm starting to think that using a > separate branch for gtk3 (like gtk itself did) is the way to go. But then you would publish two separate tarballs in webkitgtk.org ? How are you going to name them?
(In reply to Alberto Garcia from comment #8) > (In reply to Carlos Garcia Campos from comment #7) > > > > I think that from the distribution point of view any solution is > > > fine as long as the library name, pkg-config .pc file, etc. are > > > different. > > > And package version, I guess, since we are bumping ABI version, it > > would be weird to use 2.30 as the version number (or 2.32), I guess > > it should be 3.0 for the new API. > > Ok, no problem. > > > > 1) We keep producing both the gtk3 and gtk4 builds from the > > > exact same sources. > > > I'm not sure anymore about this, I'm starting to think that using a > > separate branch for gtk3 (like gtk itself did) is the way to go. > > But then you would publish two separate tarballs in webkitgtk.org ? > How are you going to name them? webkitgtk-2.30.tar.xz webkitgtk-3.0.tar.xz
(In reply to Carlos Garcia Campos from comment #9) > > But then you would publish two separate tarballs in webkitgtk.org ? > > How are you going to name them? > > webkitgtk-2.30.tar.xz > webkitgtk-3.0.tar.xz And are you going to keep them (mostly) identical feature-wise except for the GTK dependency and the API changes? It sounds a bit confusing if a user wants to know that's the 3.x equivalent of a 2.x release. Also for security advisories ... If you go that way, in Debian I'd upload a new 'webkitgtk[4]' source package for the 3.x branch and keep the existing 'webkit2gtk' package for the 2.x branch.
(In reply to Carlos Garcia Campos from comment #7) > And package version, I guess, since we are bumping ABI version, it would be > weird to use 2.30 as the version number (or 2.32), I guess it should be 3.0 > for the new API. That's going to be *really* confusing though. We'll need to remember that 2.30 GTK 3 version corresponds exactly to the 3.0 GTK 4 version. There's no reason to do that. It would only make sense if we were dropping backwards-compat with GTK 3 like we did during the WebKit2 transition. > I'm not sure anymore about this, I'm starting to think that using a separate branch for gtk3 (like gtk itself did) is the way to go. That's going to be way harder to maintain than #ifdefs. Regularly rebasing the GTK 3 branch for stable releases would be a frustrating and unnecessary task. Twice as many stable branches...? Let's stick with #ifdefs. I don't care if it shares the same tarball or not, but it *could* because there's not really any reason not to. We could even have shared with WPE (as long as the assets for both are provided in the same tarball) if we had wanted to; it doesn't really matter either way IMO.
(In reply to Michael Catanzaro from comment #11) > (In reply to Carlos Garcia Campos from comment #7) > > And package version, I guess, since we are bumping ABI version, it would be > > weird to use 2.30 as the version number (or 2.32), I guess it should be 3.0 > > for the new API. > > That's going to be *really* confusing though. We'll need to remember that > 2.30 GTK 3 version corresponds exactly to the 3.0 GTK 4 version. There's no corresponding version. > There's no > reason to do that. It would only make sense if we were dropping > backwards-compat with GTK 3 like we did during the WebKit2 transition. We are. The API with gtk4 is a new API. I think we are mixing things here. The GTK version won't be just a build option like build with WPE renderer or not, it will generate a different library with a different API. That was easy to maintain for wk1/wk2 because we had different API directories, different API tests, etc. What are we going to do with the public headers? Is gtk-doc and gobject-introspection ready to work with two APIs in the same codebase? What happens with the Since tags in the API docs if we keep the same package version for both APIs? > > I'm not sure anymore about this, I'm starting to think that using a separate branch for gtk3 (like gtk itself did) is the way to go. > > That's going to be way harder to maintain than #ifdefs. Regularly rebasing > the GTK 3 branch for stable releases would be a frustrating and unnecessary > task. Twice as many stable branches...? Let's stick with #ifdefs. We would need to decide, we could just keep the gtk3 branch in maintenance mode and only merge security fixes and important bug fixes like we do with our stable branches. Similar to what gtk3 branch will be in gtk itself, no? > I don't care if it shares the same tarball or not, but it *could* because > there's not really any reason not to. We could even have shared with WPE (as > long as the assets for both are provided in the same tarball) if we had > wanted to; it doesn't really matter either way IMO. Again, does it make sense to break the API and keep the same project version number? Because again, this not just adding a build option to link against gtk4.
We have another option tha would simplify things. If GtkAction is the only API exposed that is not available in GTK4, that's already deprecated and we have the alternative, so we can simply not break the API. We can force to build without deprecated symbols when using GTK4. Then, once we remove the GTK3 support we might consider to break the API.
(In reply to Carlos Garcia Campos from comment #12) > We are. The API with gtk4 is a new API. I think we are mixing things here. > The GTK version won't be just a build option like build with WPE renderer or > not, it will generate a different library with a different API. Of course. > That was > easy to maintain for wk1/wk2 because we had different API directories, > different API tests, etc. What are we going to do with the public headers? I would use a lot of #ifdefs, and install the headers twice in separate directories. /usr/include/webkitgtk-4.0 for GTK 3, /usr/include/webkitgtk-4 for GTK 4. (Ugh, that's not confusing at all....) > Is gtk-doc and gobject-introspection ready to work with two APIs in the same > codebase? What happens with the Since tags in the API docs if we keep the > same package version for both APIs? Good point, docs will not work. This will be a disaster. :/ I don't know what to do about it. > We would need to decide, we could just keep the gtk3 branch in maintenance > mode and only merge security fixes and important bug fixes like we do with > our stable branches. Similar to what gtk3 branch will be in gtk itself, no? That's not at all realistic, though. Currently you maintain stable branches for six months. I think we could do nine months (matching Firefox ESR, the maximum that any web engine does). Maybe we could even do 12. But as the branch gets older, this gets really hard, really fast. Once we're past six months, we can't look to see what Safari is backporting anymore, for instance, because we've outlived the Safari branch. Most security bugs never get CVEs anyway and are not tracked as such. If we want to avoid a second security apocalypse like we had with WebKitLegacy -> WebKit2, then keeping GTK 3 in trunk is critical IMO. > Again, does it make sense to break the API and keep the same project version > number? Because again, this not just adding a build option to link against > gtk4. Well it depends. If GTK 3 support remains in trunk, then yes, we should sync the version numbers and share releases. But if GTK 3 support gets removed from trunk and maintained only on a sidebranch, like you are planning, then I agree it would make sense to bump the version number. (But in this case, it will be an apocalypse for GTK 3 apps sooner rather than later, so I hope we don't do that.)
(In reply to Carlos Garcia Campos from comment #13) > We have another option tha would simplify things. If GtkAction is the only > API exposed that is not available in GTK4, that's already deprecated and we > have the alternative, so we can simply not break the API. We can force to > build without deprecated symbols when using GTK4. Then, once we remove the > GTK3 support we might consider to break the API. I think both ways are OK. GTK 4 is such a major API break that it makes sense to me to do API breaks only in the GTK 4 API, but of course we don't have to. The two changes I really want to see are (a) sandbox enabled by default for apps using GTK 4, with no possibility to disable it, and (b) PSON enabled by default for apps using GTK 4. I also think there's also value in changing the snapshot API to not use cairo.
(In reply to Michael Catanzaro from comment #14) > (In reply to Carlos Garcia Campos from comment #12) > > We are. The API with gtk4 is a new API. I think we are mixing things here. > > The GTK version won't be just a build option like build with WPE renderer or > > not, it will generate a different library with a different API. > > Of course. > > > That was > > easy to maintain for wk1/wk2 because we had different API directories, > > different API tests, etc. What are we going to do with the public headers? > > I would use a lot of #ifdefs, and install the headers twice in separate > directories. /usr/include/webkitgtk-4.0 for GTK 3, /usr/include/webkitgtk-4 > for GTK 4. (Ugh, that's not confusing at all....) > > > Is gtk-doc and gobject-introspection ready to work with two APIs in the same > > codebase? What happens with the Since tags in the API docs if we keep the > > same package version for both APIs? > > Good point, docs will not work. This will be a disaster. :/ I don't know > what to do about it. > > > We would need to decide, we could just keep the gtk3 branch in maintenance > > mode and only merge security fixes and important bug fixes like we do with > > our stable branches. Similar to what gtk3 branch will be in gtk itself, no? > > That's not at all realistic, though. Currently you maintain stable branches > for six months. I think we could do nine months (matching Firefox ESR, the > maximum that any web engine does). Maybe we could even do 12. But as the > branch gets older, this gets really hard, really fast. Once we're past six > months, we can't look to see what Safari is backporting anymore, for > instance, because we've outlived the Safari branch. > > Most security bugs never get CVEs anyway and are not tracked as such. > > If we want to avoid a second security apocalypse like we had with > WebKitLegacy -> WebKit2, then keeping GTK 3 in trunk is critical IMO. > > > Again, does it make sense to break the API and keep the same project version > > number? Because again, this not just adding a build option to link against > > gtk4. > > Well it depends. If GTK 3 support remains in trunk, then yes, we should sync > the version numbers and share releases. But if GTK 3 support gets removed > from trunk and maintained only on a sidebranch, like you are planning, then > I agree it would make sense to bump the version number. (But in this case, > it will be an apocalypse for GTK 3 apps sooner rather than later, so I hope > we don't do that.) I'm not planning anything, just considering all the options we have to make a decision.
As it seems uncertain what exactly we will decide to do regarding maintenance of the GTK3 support, I would at least like to land a small patch which would allow us to work in trunk adding the GTK4 support in parallel, without branching for now. As we progress, I think we will have a much better idea of whether it is reasonable to continue supporting both GTK3 and GTK4 in trunk—if it gets to the point where it starts to look unwieldy, we can create a GTK3 support branch at that point. For those wondering: at the moment in my mind it sounds better to keep both in trunk and buildable from the same tarballs, mainly because that would automatically get both GTK3 and GTK4 all the fixes and also allow having a GTK4 EWS builder. On the other hand, there is quite some uncertainty about the amount of complexity that having both versions supported in trunk will be, so I am definitely open to reconsider as we know more :) Checking all the previous messages, I will update the patch in this bug to do the following when building against GTK4: - Add the USE_GTK4 build option. - Keep the same name+version for the JSC library, as ideally both GTK3 and GTK4 builds can use the same. - Leave the name of the WebKitWebDriver untouched, as it does not link to GTK. - Change the name+version of the main library to libwebkitgtk-5.0 (major API version bump, GTK3 builds will keep using 4.x) removing the “2” from the name, and webkitgtk-5.0.pc for the pkg-config file. - Programs WebKit{Web,Network,*}Process will be installed into <libdir>/webkitgtk-5.0 - Headers will be installed into <prefix>/include/webkitgtk-5.0 These changes are the path of least effort right now to allow installing GTK3 and GTK4 builds in parallel for development. If we want to do more changes we have still plenty of time before the first GTK4 stable release comes out, and some more before applications start being ported.
(In reply to Adrian Perez from comment #17) > [...] > - Change the name+version of the main library to libwebkitgtk-5.0 > (major API version bump, GTK3 builds will keep using 4.x) removing > the “2” from the name, and webkitgtk-5.0.pc for the pkg-config file. > - Programs WebKit{Web,Network,*}Process will be installed into > <libdir>/webkitgtk-5.0 > - Headers will be installed into <prefix>/include/webkitgtk-5.0 I'm curious, your idea its to do a new major release of WebKitGTK (from 2.X.Y to (maybe) 4.0.0?) or we will continue using a 2.x.y numeration schema for the release versions?
Comment on attachment 395737 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=395737&action=review >>>> Source/cmake/OptionsGTK.cmake:10 >>>> + set(WEBKITGTK_API_VERSION 5.0) >>> >>> Maybe we could use API version 0.0 and call it libwebkit2gtk4-0.0? (And eventually bump to 1.0 once it's ready to become stable?) That might be less confusing than expecting people to know libwebkit2gtk-5.0 in the GTK 4 version? (Yes, I know it doesn't match GTK 3's libwebkit2gtk-4.0, but we can't ever change that....) >>> >>> That might also be a nice nudge to distros on how to standardize the package naming. Distros are currently split between webkit2gtk and webkit2gtk3 (and previously, webkitgtk3 and webkitgtk4, amazingly confusing!). I think in Fedora/RHEL we will call this webkit2gtk4, so.... >> >> I think that complicates things, since bumping the ABI is not just using a new version of WEBKITGTK_API_VERSION. If we want to do it, maybe we can also remove 2, since webkit2 is the only webkit layer nowadays. > > GTK4 went with simplifying the installed library name. It is using “libgtk-4” > as basename. I think we could do the same and use “libwebkitgtk-4”. This way > we get to remove the “2” (as there will be no WebKit1), it will encourage > distributions to use “webkitgtk4” or “webkitgtk-4” as package name, and it > will be clear which GTK version the library uses. > > WDYT? +1 to the idea of using libwebkitgtk-4. It will be less confusing.
(In reply to Adrian Perez from comment #17) > As it seems uncertain what exactly we will decide to do regarding > maintenance of the GTK3 support, I would at least like to land a > small patch which would allow us to work in trunk adding the GTK4 > support in parallel, without branching for now. As we progress, I > think we will have a much better idea of whether it is reasonable > to continue supporting both GTK3 and GTK4 in trunk—if it gets to > the point where it starts to look unwieldy, we can create a GTK3 > support branch at that point. Ok. > For those wondering: at the moment in my mind it sounds better to > keep both in trunk and buildable from the same tarballs, mainly > because that would automatically get both GTK3 and GTK4 all the > fixes and also allow having a GTK4 EWS builder. On the other hand, > there is quite some uncertainty about the amount of complexity that > having both versions supported in trunk will be, so I am definitely > open to reconsider as we know more :) > > Checking all the previous messages, I will update the patch in this > bug to do the following when building against GTK4: > > - Add the USE_GTK4 build option. > - Keep the same name+version for the JSC library, as ideally both > GTK3 and GTK4 builds can use the same. > - Leave the name of the WebKitWebDriver untouched, as it does not > link to GTK. > - Change the name+version of the main library to libwebkitgtk-5.0 > (major API version bump, GTK3 builds will keep using 4.x) removing > the “2” from the name, and webkitgtk-5.0.pc for the pkg-config file. > - Programs WebKit{Web,Network,*}Process will be installed into > <libdir>/webkitgtk-5.0 > - Headers will be installed into <prefix>/include/webkitgtk-5.0 For now I think we don't need to care about pkg-config nor installation, so I would just add the build option and add the new library. > These changes are the path of least effort right now to allow installing > GTK3 and GTK4 builds in parallel for development. Do we need to install with GTK$ at this moment? > If we want to do more > changes we have still plenty of time before the first GTK4 stable release > comes out, and some more before applications start being ported. I prefer to do fewer changes for now :-)
(In reply to Carlos Garcia Campos from comment #20) > (In reply to Adrian Perez from comment #17) > > As it seems uncertain what exactly we will decide to do regarding > > maintenance of the GTK3 support, I would at least like to land a > > small patch which would allow us to work in trunk adding the GTK4 > > support in parallel, without branching for now. As we progress, I > > think we will have a much better idea of whether it is reasonable > > to continue supporting both GTK3 and GTK4 in trunk—if it gets to > > the point where it starts to look unwieldy, we can create a GTK3 > > support branch at that point. > > Ok. > > > For those wondering: at the moment in my mind it sounds better to > > keep both in trunk and buildable from the same tarballs, mainly > > because that would automatically get both GTK3 and GTK4 all the > > fixes and also allow having a GTK4 EWS builder. On the other hand, > > there is quite some uncertainty about the amount of complexity that > > having both versions supported in trunk will be, so I am definitely > > open to reconsider as we know more :) > > > > Checking all the previous messages, I will update the patch in this > > bug to do the following when building against GTK4: > > > > - Add the USE_GTK4 build option. > > - Keep the same name+version for the JSC library, as ideally both > > GTK3 and GTK4 builds can use the same. > > - Leave the name of the WebKitWebDriver untouched, as it does not > > link to GTK. > > - Change the name+version of the main library to libwebkitgtk-5.0 > > (major API version bump, GTK3 builds will keep using 4.x) removing > > the “2” from the name, and webkitgtk-5.0.pc for the pkg-config file. > > - Programs WebKit{Web,Network,*}Process will be installed into > > <libdir>/webkitgtk-5.0 > > - Headers will be installed into <prefix>/include/webkitgtk-5.0 > > For now I think we don't need to care about pkg-config nor installation, so > I would just add the build option and add the new library. Okay, let's do that. > > These changes are the path of least effort right now to allow installing > > GTK3 and GTK4 builds in parallel for development. > > Do we need to install with GTK$ at this moment? Not really; we can live with uninstalled builds for a good while :] > > If we want to do more > > changes we have still plenty of time before the first GTK4 stable release > > comes out, and some more before applications start being ported. > > I prefer to do fewer changes for now :-) :-)
Created attachment 396271 [details] Patch for landing
Committed r260006: <https://trac.webkit.org/changeset/260006> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396271 [details].
<rdar://problem/61716297>