210154 2020-04-07 14:14:12 -0700 [GTK][CMake] Introduce an USE_GTK4 build option 2020-04-13 08:01:15 -0700 1 1 1 Unclassified WebKit Tools / Tests WebKit Local Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 210110 210100 210160 1 aperez aperez annulen aperez berto cgarcia clopez csaavedra darin don.olmstead ews-watchlist fujii gyuyoung.kim mcatanzaro ross.kirsling ryuan.choi sergio webkit-bug-importer oldest_to_newest 1638793 0 aperez 2020-04-07 14:14:12 -0700 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. 1638797 1 395737 aperez 2020-04-07 14:20:57 -0700 Created attachment 395737 Patch 1638907 2 395737 mcatanzaro 2020-04-07 17:59:58 -0700 Comment on attachment 395737 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.) 1638950 3 395737 cgarcia 2020-04-07 23:41:01 -0700 Comment on attachment 395737 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. 1638964 4 aperez 2020-04-08 00:56:02 -0700 (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. 1639022 5 mcatanzaro 2020-04-08 06:21:17 -0700 (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. 1639081 6 berto 2020-04-08 08:56:36 -0700 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? 1639542 7 cgarcia 2020-04-09 02:41:09 -0700 (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. 1639548 8 berto 2020-04-09 02:59:00 -0700 (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? 1639551 9 cgarcia 2020-04-09 03:13:43 -0700 (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 1639559 10 berto 2020-04-09 03:49:58 -0700 (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. 1639571 11 mcatanzaro 2020-04-09 04:53:25 -0700 (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. 1639590 12 cgarcia 2020-04-09 05:40:58 -0700 (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. 1639598 13 cgarcia 2020-04-09 06:05:01 -0700 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. 1639640 14 mcatanzaro 2020-04-09 07:53:16 -0700 (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.) 1639642 15 mcatanzaro 2020-04-09 08:00:12 -0700 (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. 1640086 16 cgarcia 2020-04-10 02:48:47 -0700 (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. 1640156 17 aperez 2020-04-10 07:21:46 -0700 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. 1640164 18 clopez 2020-04-10 07:54:58 -0700 (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? 1640166 19 395737 clopez 2020-04-10 07:59:10 -0700 Comment on attachment 395737 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. 1640203 20 cgarcia 2020-04-10 09:03:51 -0700 (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 :-) 1640412 21 aperez 2020-04-10 16:16:37 -0700 (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 :-) :-) 1640847 22 396271 aperez 2020-04-13 07:24:57 -0700 Created attachment 396271 Patch for landing 1640865 23 ews-feeder 2020-04-13 08:00:14 -0700 Committed r260006: <https://trac.webkit.org/changeset/260006> All reviewed patches have been landed. Closing bug and clearing flags on attachment 396271. 1640866 24 webkit-bug-importer 2020-04-13 08:01:15 -0700 <rdar://problem/61716297> 395737 2020-04-07 14:20:57 -0700 2020-04-13 07:24:52 -0700 Patch bug-210154-20200408002055.patch text/plain 2789 aperez U3VidmVyc2lvbiBSZXZpc2lvbjogMjU5NjQyCmRpZmYgLS1naXQgYS9Tb3VyY2UvY21ha2UvT3B0 aW9uc0dUSy5jbWFrZSBiL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCmluZGV4IDA4ZWQy ZjhmNjE2ZThmOWE2Y2Y1MDM5NDg2MWVhYWE5ODRiYzBlYzIuLjI1MzI2MGRlMWI2NDJhZGQ5YmM0 YzdmMDA2YjllZDRlYjYxYzBhNzAgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RL LmNtYWtlCisrKyBiL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCkBAIC0xLDExICsxLDIy IEBACiBpbmNsdWRlKEdOVUluc3RhbGxEaXJzKQogaW5jbHVkZShWZXJzaW9uaW5nVXRpbHMpCiAK K1dFQktJVF9PUFRJT05fQkVHSU4oKQorV0VCS0lUX09QVElPTl9ERUZJTkUoVVNFX0dUSzQgIldo ZXRoZXIgdG8gZW5hYmxlIHVzYWdlIG9mIEdUSzQgaW5zdGVhZCBvZiBHVEszLiIgUFVCTElDIE9G RikKKwogU0VUX1BST0pFQ1RfVkVSU0lPTigyIDI5IDApCi1zZXQoV0VCS0lUR1RLX0FQSV9WRVJT SU9OIDQuMCkKIAotQ0FMQ1VMQVRFX0xJQlJBUllfVkVSU0lPTlNfRlJPTV9MSUJUT09MX1RSSVBM RShXRUJLSVQgODIgMCA0NSkKLUNBTENVTEFURV9MSUJSQVJZX1ZFUlNJT05TX0ZST01fTElCVE9P TF9UUklQTEUoSkFWQVNDUklQVENPUkUgMzUgMCAxNykKK2lmIChVU0VfR1RLNCkKKyAgICBzZXQo V0VCS0lUR1RLX0FQSV9WRVJTSU9OIDUuMCkKKyAgICBzZXQoR1RLX01JTklNVU1fVkVSU0lPTiAz Ljk4LjIpCisgICAgQ0FMQ1VMQVRFX0xJQlJBUllfVkVSU0lPTlNfRlJPTV9MSUJUT09MX1RSSVBM RShXRUJLSVQgODMgMCAwKQorICAgIENBTENVTEFURV9MSUJSQVJZX1ZFUlNJT05TX0ZST01fTElC VE9PTF9UUklQTEUoSkFWQVNDUklQVENPUkUgMzYgMCAwKQorZWxzZSAoKQorICAgIHNldChXRUJL SVRHVEtfQVBJX1ZFUlNJT04gNC4wKQorICAgIHNldChHVEtfTUlOSU1VTV9WRVJTSU9OIDMuMjIu MCkKKyAgICBDQUxDVUxBVEVfTElCUkFSWV9WRVJTSU9OU19GUk9NX0xJQlRPT0xfVFJJUExFKFdF QktJVCA4MiAwIDQ1KQorICAgIENBTENVTEFURV9MSUJSQVJZX1ZFUlNJT05TX0ZST01fTElCVE9P TF9UUklQTEUoSkFWQVNDUklQVENPUkUgMzUgMCAxNykKK2VuZGlmICgpCiAKICMgVGhlc2UgYXJl IHNoYXJlZCB2YXJpYWJsZXMsIGJ1dCB3ZSBzcGVjaWFsIGNhc2UgdGhlaXIgZGVmaW5pdGlvbiBz byB0aGF0IHdlIGNhbiB1c2UgdGhlCiAjIENNQUtFX0lOU1RBTExfKiB2YXJpYWJsZXMgdGhhdCBh cmUgcG9wdWxhdGVkIGJ5IHRoZSBHTlVJbnN0YWxsRGlycyBtYWNyby4KQEAgLTI3LDcgKzM4LDcg QEAgZmluZF9wYWNrYWdlKEZvbnRjb25maWcgMi44LjAgUkVRVUlSRUQpCiBmaW5kX3BhY2thZ2Uo RnJlZXR5cGUgMi40LjIgUkVRVUlSRUQpCiBmaW5kX3BhY2thZ2UoTGliR2NyeXB0IDEuNi4wIFJF UVVJUkVEKQogZmluZF9wYWNrYWdlKEdMSUIgMi40NC4wIFJFUVVJUkVEIENPTVBPTkVOVFMgZ2lv IGdpby11bml4IGdvYmplY3QgZ3RocmVhZCBnbW9kdWxlKQotZmluZF9wYWNrYWdlKEdUSyAzLjIy LjAgUkVRVUlSRUQpCitmaW5kX3BhY2thZ2UoR1RLICR7R1RLX01JTklNVU1fVkVSU0lPTn0gUkVR VUlSRUQpCiBmaW5kX3BhY2thZ2UoSGFyZkJ1enogMC45LjE4IFJFUVVJUkVEIENPTVBPTkVOVFMg SUNVKQogZmluZF9wYWNrYWdlKElDVSA2MC4yIFJFUVVJUkVEIENPTVBPTkVOVFMgZGF0YSBpMThu IHVjKQogZmluZF9wYWNrYWdlKEpQRUcgUkVRVUlSRUQpCkBAIC00NSw4ICs1Niw2IEBAIGZpbmRf cGFja2FnZShHVEtVbml4UHJpbnQpCiBmaW5kX3BhY2thZ2UoT3BlbkdMKQogZmluZF9wYWNrYWdl KE9wZW5HTEVTMikKIAotV0VCS0lUX09QVElPTl9CRUdJTigpCi0KIGluY2x1ZGUoR1N0cmVhbWVy RGVmaW5pdGlvbnMpCiAKIFNFVF9BTkRfRVhQT1NFX1RPX0JVSUxEKFVTRV9BVEsgVFJVRSkKZGlm ZiAtLWdpdCBhL0NoYW5nZUxvZyBiL0NoYW5nZUxvZwppbmRleCA5ZDk0YmQ4YjQyMmZiOGVjODIy YjVjNDg3NTNhZGQ2ZjA3NjkyMmE2Li5iM2E3NDlmNTgwMzU5NzlhZGJiOWI1YzBhMGMwOTQ0YWI0 YTExMzk5IDEwMDY0NAotLS0gYS9DaGFuZ2VMb2cKKysrIGIvQ2hhbmdlTG9nCkBAIC0xLDMgKzEs MTUgQEAKKzIwMjAtMDQtMDcgIEFkcmlhbiBQZXJleiBkZSBDYXN0cm8gIDxhcGVyZXpAaWdhbGlh LmNvbT4KKworICAgICAgICBbR1RLXVtDTWFrZV0gSW50cm9kdWNlIGFuIFVTRV9HVEs0IGJ1aWxk IG9wdGlvbgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9 MjEwMTU0CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg KiBTb3VyY2UvY21ha2UvT3B0aW9uc0dUSy5jbWFrZTogQWRkIGEgbmV3IFVTRV9HVEs0IHB1Ymxp YyBidWlsZCBvcHRpb24sIHdoaWNoIGRlZmF1bHRzCisgICAgICAgIHRvIEZBTFNFIGZvciBub3cs IGFuZCBkZXBlbmRpbmcgb24gaXRzIHZhbHVlIHNldCBkaWZmZXJlbnQgQVBJIGFuZCBsaWJyYXJ5 IHZlcnNpb25zIHRvCisgICAgICAgIGFsbG93IGluc3RhbGxhdGlvbiBpbiBwYXJhbGxlbCBvZiBi dWlsZHMgdGFyZ2V0aW5nIEdUSzMgYW5kIEdUSzQ7IGNob29zZSB0aGUgcmVxdWlyZWQKKyAgICAg ICAgdmVyc2lvbiBvZiBHVEsgZGVwZW5kaW5nIG9uIHRoZSB2YWx1ZSBvZiB0aGUgb3B0aW9uIGFz IHdlbGwuCisKIDIwMjAtMDQtMDcgIEFkcmlhbiBQZXJleiBkZSBDYXN0cm8gIDxhcGVyZXpAaWdh bGlhLmNvbT4KIAogICAgICAgICBbR1RLXSBDTWFrZSBmaW5kIG1vZHVsZSBmb3IgR1RLNAo= 396271 2020-04-13 07:24:57 -0700 2020-04-13 08:00:15 -0700 Patch for landing bug-210154-20200413172455.patch text/plain 2996 aperez U3VidmVyc2lvbiBSZXZpc2lvbjogMjU5OTM0CmRpZmYgLS1naXQgYS9Tb3VyY2UvY21ha2UvT3B0 aW9uc0dUSy5jbWFrZSBiL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCmluZGV4IDZmZjhj Mzk5MjJhNGYzMTI5YjY4N2FlMGY5ZDE1ZGUzZWRjNjRlMDMuLmZhNjhmNzg0OWQ5NTYwMTFjYzMy NmI2YTNlNTAxNTk5MDA3MDZjNzggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RL LmNtYWtlCisrKyBiL1NvdXJjZS9jbWFrZS9PcHRpb25zR1RLLmNtYWtlCkBAIC0xLDEwICsxLDIx IEBACiBpbmNsdWRlKEdOVUluc3RhbGxEaXJzKQogaW5jbHVkZShWZXJzaW9uaW5nVXRpbHMpCiAK K1dFQktJVF9PUFRJT05fQkVHSU4oKQorV0VCS0lUX09QVElPTl9ERUZJTkUoVVNFX0dUSzQgIldo ZXRoZXIgdG8gZW5hYmxlIHVzYWdlIG9mIEdUSzQgaW5zdGVhZCBvZiBHVEszLiIgUFVCTElDIE9G RikKKwogU0VUX1BST0pFQ1RfVkVSU0lPTigyIDI5IDApCi1zZXQoV0VCS0lUR1RLX0FQSV9WRVJT SU9OIDQuMCkKIAotQ0FMQ1VMQVRFX0xJQlJBUllfVkVSU0lPTlNfRlJPTV9MSUJUT09MX1RSSVBM RShXRUJLSVQgODIgMCA0NSkKK2lmIChVU0VfR1RLNCkKKyAgICBzZXQoV0VCS0lUR1RLX0FQSV9W RVJTSU9OIDUuMCkKKyAgICBzZXQoR1RLX01JTklNVU1fVkVSU0lPTiAzLjk4LjIpCisgICAgQ0FM Q1VMQVRFX0xJQlJBUllfVkVSU0lPTlNfRlJPTV9MSUJUT09MX1RSSVBMRShXRUJLSVQgMCAwIDAp CitlbHNlICgpCisgICAgc2V0KFdFQktJVEdUS19BUElfVkVSU0lPTiA0LjApCisgICAgc2V0KEdU S19NSU5JTVVNX1ZFUlNJT04gMy4yMi4wKQorICAgIENBTENVTEFURV9MSUJSQVJZX1ZFUlNJT05T X0ZST01fTElCVE9PTF9UUklQTEUoV0VCS0lUIDgyIDAgNDUpCitlbmRpZiAoKQorCiBDQUxDVUxB VEVfTElCUkFSWV9WRVJTSU9OU19GUk9NX0xJQlRPT0xfVFJJUExFKEpBVkFTQ1JJUFRDT1JFIDM1 IDAgMTcpCiAKICMgVGhlc2UgYXJlIHNoYXJlZCB2YXJpYWJsZXMsIGJ1dCB3ZSBzcGVjaWFsIGNh c2UgdGhlaXIgZGVmaW5pdGlvbiBzbyB0aGF0IHdlIGNhbiB1c2UgdGhlCkBAIC0yNyw3ICszOCw3 IEBAIGZpbmRfcGFja2FnZShGb250Y29uZmlnIDIuOC4wIFJFUVVJUkVEKQogZmluZF9wYWNrYWdl KEZyZWV0eXBlIDIuNC4yIFJFUVVJUkVEKQogZmluZF9wYWNrYWdlKExpYkdjcnlwdCAxLjYuMCBS RVFVSVJFRCkKIGZpbmRfcGFja2FnZShHTElCIDIuNDQuMCBSRVFVSVJFRCBDT01QT05FTlRTIGdp byBnaW8tdW5peCBnb2JqZWN0IGd0aHJlYWQgZ21vZHVsZSkKLWZpbmRfcGFja2FnZShHVEsgMy4y Mi4wIFJFUVVJUkVEKQorZmluZF9wYWNrYWdlKEdUSyAke0dUS19NSU5JTVVNX1ZFUlNJT059IFJF UVVJUkVEKQogZmluZF9wYWNrYWdlKEhhcmZCdXp6IDAuOS4xOCBSRVFVSVJFRCBDT01QT05FTlRT IElDVSkKIGZpbmRfcGFja2FnZShJQ1UgNjAuMiBSRVFVSVJFRCBDT01QT05FTlRTIGRhdGEgaTE4 biB1YykKIGZpbmRfcGFja2FnZShKUEVHIFJFUVVJUkVEKQpAQCAtNDUsOCArNTYsNiBAQCBmaW5k X3BhY2thZ2UoR1RLVW5peFByaW50KQogZmluZF9wYWNrYWdlKE9wZW5HTCkKIGZpbmRfcGFja2Fn ZShPcGVuR0xFUzIpCiAKLVdFQktJVF9PUFRJT05fQkVHSU4oKQotCiBpbmNsdWRlKEdTdHJlYW1l ckRlZmluaXRpb25zKQogCiBTRVRfQU5EX0VYUE9TRV9UT19CVUlMRChVU0VfQVRLIFRSVUUpCmRp ZmYgLS1naXQgYS9DaGFuZ2VMb2cgYi9DaGFuZ2VMb2cKaW5kZXggZGI3NDI4MGM1OTIzN2MwYzVi ZTE5ZDcxNjkwZTY4OGMyNjBhMmQxYy4uMGQ3Nzk3YzMxNTE1MmI2NThkZjYwZWQzYWQ4OTIzNzUz NzI3MDFlMiAxMDA2NDQKLS0tIGEvQ2hhbmdlTG9nCisrKyBiL0NoYW5nZUxvZwpAQCAtMSwzICsx LDIxIEBACisyMDIwLTA0LTEwICBBZHJpYW4gUGVyZXogZGUgQ2FzdHJvICA8YXBlcmV6QGlnYWxp YS5jb20+CisKKyAgICAgICAgW0dUS11bQ01ha2VdIEludHJvZHVjZSBhbiBVU0VfR1RLNCBidWls ZCBvcHRpb24KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTIxMDE1NAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAg IERvIHRoZSBiYXJlIG1pbmltdW0gY2hhbmdlcyB0byBidWlsZCBhZ2FpbnN0IEdUSzQgYW5kIHBy b2R1Y2UgYSBXZWJLaXQgcG9ydCBsaWJyYXJ5IHdpdGggYQorICAgICAgICBkaWZmZXJlbnQgbmFt ZSB0aGFuIEdUSzMgYnVpbGRzLiBOb3RlIHRoYXQgdGhpcyBkb2VzIG5vdCBhdHRlbXB0IHRvIG1h a2UgdGhlIGJ1aWx0IGFydGlmYWN0cworICAgICAgICBwYXJhbGxlbC1pbnN0YWxsYWJsZSB5ZXQs IHRob3VnaCBhdCBsZWFzdCB0aGUgbWFpbiBsaWJyYXJ5LCBoZWFkZXJzLCBhbmQgdGhlIHBrZy1j b25maWcgLnBjCisgICAgICAgIGZpbGUgc2hvdWxkIGJlIHNhZmUgdG8gaW5zdGFsbC4gVGhlIGZp bmFsIG5hbWVzIGZvciBidWlsdCBhcnRpZmFjdHMgZm9yIEdUSzQgYnVpbGRzIG1heQorICAgICAg ICBzdGlsbCBjaGFuZ2UuCisKKyAgICAgICAgKiBTb3VyY2UvY21ha2UvT3B0aW9uc0dUSy5jbWFr ZTogQWRkIGEgbmV3IFVTRV9HVEs0IHB1YmxpYyBidWlsZCBvcHRpb24sIHdoaWNoIGRlZmF1bHRz CisgICAgICAgIHRvIEZBTFNFIGZvciBub3csIGFuZCBkZXBlbmRpbmcgb24gaXRzIHZhbHVlIGNo b29zZSB0aGUgcmVxdWlyZWQgdmVyc2lvbiBvZiBHVEsgYW5kIHNldAorICAgICAgICBhIGRpZmZl cmVudCBBUEkgdmVyc2lvbiB2ZXJzaW9ucy4gVGhpcyBpcyBlbm91Z2ggdG8gYnVpbGQgYSBsaWJy YXJ5IHdpdGggYSBkaWZmZXJlbnQKKyAgICAgICAgbmFtZSAobGlid2Via2l0Mmd0ay01LjAgdnMu IGxpYndlYmtpdDJndGstNC4wKSB3aGVuIEdUSzQgaXMgaW4gdXNlLgorCiAyMDIwLTA0LTEwICBQ aGlsaXBwZSBOb3JtYW5kICA8cG5vcm1hbmRAaWdhbGlhLmNvbT4KIAogICAgICAgICBbRmxhdHBh ayBTREtdIEltcHJvdmVkIHNjY2FjaGUgc3VwcG9ydAo=