webkit-gtk and gtk4

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

recently I noticed that both of these packages failed to build on
NetBSD/macppc 10.0_BETA, with a similar build failure.

webkit-gtk failed with

[ 53%] Building CXX object Source/WebCore/CMakeFiles/WebCore.dir/platform/graphics/PlatformDisplay.cpp.o
/usr/pkgsrc/www/webkit-gtk/work/webkitgtk-2.36.8/Source/WebCore/platform/graphics/PlatformDisplay.cpp:76:10: fatal error: EGL/egl.h: No such file or directory
   76 | #include <EGL/egl.h>
      |          ^~~~~~~~~~~
compilation terminated.

whereas gtk4 fails while building gdkdisplay-x11.c with

In file included from /usr/pkgsrc/x11/gtk4/work/.buildlink/include/epoxy/egl.h:4
6,
                 from ../gdk/x11/gdkdisplay-x11.c:59:
/usr/pkgsrc/x11/gtk4/work/.buildlink/include/epoxy/egl_generated.h:11:10: fatal 
error: EGL/eglplatform.h: No such file or directory
   11 | #include "EGL/eglplatform.h"
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

The common theme for both of these appears to be dependence on
some form of GL.

For webkit-gtk the build can be made to succeed to disable the
opengl option.

However, both of the above two headers are present as part of the
MesaLib package (version 21.3.9nb1), but that is apparently not
being buldlink'ed by either of the two packages or their
dependencies.

While webkit-gtk has an option for opengl, the same does not
appear to be the case for gtk4 -- the source appears to
unconditionally depend on opengl.

I must admit that I'm not too familiar with GL, whether there is
specific hardware requirements, or whether just using MesaLib on
macppc would be sufficient.  If the latter, this may be a simpler
case of properly detecting that base system X11 doesn't supply
the required functionality, and that MesaLib needs to be used.

I'm guessing that there are more platforms which don't have GL
with sufficient functionality in the base system's X11, and that
there will eventually be a push for a move from gtk3 to gtk4, and
it would be nice go get a few more ports along for the ride.


And ... while mentioning the package, the build for webkit-gtk
with disabled opengl took about 30.5 hours wallclock time on my
dual-CPU 1.25G macppc with 2G memory.  Some of the cc1plus
processes bloated to 1.7GB virtual size, and put quite a strain
on the system, fighting for real memory with the other cc1plus
process.  I actually temporarily stopped the other one (twice!)
so the system would not page itself to death...  So even if it
can be made to build, it's in the class of rust or worse in terms
of strain on the system.  But I guess there's no reason to
disable-by-default on certain systems for that reason.

Comments?  Fixes?  Suggestions?

Regards,

- Håvard