Bug 210154 – [GTK][CMake] Introduce an USE_GTK4 build option

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Adrian Perez]

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.

[Adrian Perez]

Created attachment 395737 [details]
Patch

[Michael Catanzaro]

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.)

[Carlos Garcia Campos]

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.

[Adrian Perez]

(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.

[Michael Catanzaro]

(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.

[Alberto Garcia]

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?

[Carlos Garcia Campos]

(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.

[Alberto Garcia]

(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?

[Carlos Garcia Campos]

(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

[Alberto Garcia]

(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.

[Michael Catanzaro]

(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.

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

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.

[Michael Catanzaro]

(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.)

[Michael Catanzaro]

(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.

[Carlos Garcia Campos]

(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.

[Adrian Perez]

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.

[Carlos Alberto Lopez Perez]

(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?

[Carlos Alberto Lopez Perez]

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.

[Carlos Garcia Campos]

(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 :-)

[Adrian Perez]

(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 :-)

:-)

[Adrian Perez]

Created attachment 396271 [details]
Patch for landing

[EWS]

Committed r260006: <https://trac.webkit.org/changeset/260006>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 396271 [details].

[Radar WebKit Bug Importer]

<rdar://problem/61716297>