Created attachment 422796 [details] Initial patch Initial patch. To make the usage of gtk4 platform automatic, it first checks the contents of cmakeconfig.h, and if not present, runs an executable to check the GTK version. This fallback will be used in the test-only bots, as they do not download the cmakeconfig.h. It's missing the actual TestExpectation file and a way to test the MiniBrowser fallback check in the webkitpy unittests.\n\nIf this fallback feels too complicated, we can drop it and move to use some envvar in the bots to pass --additional-platform-directory.

Created attachment 423011 [details] Patch with initial expectations

Comment on attachment 423011 [details] Patch with initial expectations View in context: https://bugs.webkit.org/attachment.cgi?id=423011&action=review > Tools/Scripts/webkitpy/port/gtk.py:307 > + mb = self._build_path('bin', 'MiniBrowser') > + output = self._executive.run_command([mb, "--gtk-version"]) > + return output.startswith("GTK 4") Maybe the ldd output could be parsed?

Comment on attachment 423011 [details] Patch with initial expectations View in context: https://bugs.webkit.org/attachment.cgi?id=423011&action=review >> Tools/Scripts/webkitpy/port/gtk.py:307 >> + return output.startswith("GTK 4") > > Maybe the ldd output could be parsed? I think we could just check the name of the lib, for GTK4 build the library is libwebkit2gtk-5.0.so

Comment on attachment 423011 [details] Patch with initial expectations View in context: https://bugs.webkit.org/attachment.cgi?id=423011&action=review > LayoutTests/platform/gtk4/TestExpectations:35 > +webkit.org/b/223108 http/tests/dom/noreferrer-window-not-targetable.html [ Crash ] We can probably investigate and fix this bug before adding gtk4 specific expectations, I guess the bot is exiting early, so it's not easy to know other differences.

Created attachment 423142 [details] Patch checking ldd output Also removed the MiniBrowser chances and the expectations from already solved bug, leaving only the expectations stub.

(In reply to Carlos Garcia Campos from comment #4) > Comment on attachment 423011 [details] > Patch with initial expectations > > View in context: > https://bugs.webkit.org/attachment.cgi?id=423011&action=review > > >> Tools/Scripts/webkitpy/port/gtk.py:307 > >> + return output.startswith("GTK 4") > > > > Maybe the ldd output could be parsed? > > I think we could just check the name of the lib, for GTK4 build the library > is libwebkit2gtk-5.0.so Isn't it possible to just check the library name?

(In reply to Carlos Garcia Campos from comment #7) > (In reply to Carlos Garcia Campos from comment #4) > > Comment on attachment 423011 [details] > > Patch with initial expectations > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=423011&action=review > > > > >> Tools/Scripts/webkitpy/port/gtk.py:307 > > >> + return output.startswith("GTK 4") > > > > > > Maybe the ldd output could be parsed? > > > > I think we could just check the name of the lib, for GTK4 build the library > > is libwebkit2gtk-5.0.so > > Isn't it possible to just check the library name? Do you mean just checking if libwebkitgtk2gtk-5.0.so is present in `self._build_path('lib')`? That's an option too, avoiding the executive calls. The only issue would be the corner case of reusing the build dir to build both GTK3/GTK4, but script can log a warning if it finds both. I'll update the patch with this approach.

(In reply to Lauro Moura from comment #8) > The only issue would be the corner case of reusing the build dir to build > both GTK3/GTK4, but script can log a warning if it finds both. > Well, in this case the latest cmakeconfig would provide the right version. The issue would be the even more corner case of a bot downloading both the binary products of both versions.

I don't think we should reuse the same build dir for gtk3 and gtk4 builds.

Created attachment 423196 [details] Patch checking for filename

Comment on attachment 423196 [details] Patch checking for filename View in context: https://bugs.webkit.org/attachment.cgi?id=423196&action=review > Tools/Scripts/webkitpy/port/gtk.py:303 > + # The test-only bots won't have a cmake config file as they download > + # only the binaries from the build-only bots. This should work in both cases, I don't think we need to parse cmakeconfig.h

Created attachment 423320 [details] Patch without cmakeconfig check

Committed r274474: <https://commits.webkit.org/r274474> All reviewed patches have been landed. Closing bug and clearing flags on attachment 423320 [details].

<rdar://problem/75475455>