This is looking pretty good. I had no difficulty building qt5-webkit or any of the dependents (not that it was necessary to do so, just verifying). I haven't found any issues with updated webkit in a couple weeks of use.

In D11594#240330, @jbeich wrote:

Why do you focus on the style rather than correctness? Don't you care which version ends up upstream?

Using a snapshot is a better solution than trying to backport support for LLVM 4.0 while we await the release of beignet 1.4.

Commenting the patch files to explain their purpose is a better solution. Just because patches may be combined doesn't mean it's a good idea nor the preferred way.

This appears completely backwards. Why would you lump the patches together when the preferred way to is to use makepatch? This only makes maintenance harder.

In D11557#239102, @tcberner wrote:

On second thought --

• don't you need to check whether the sysctl exists? -- or has it trickled down to all the versions?

bump PORTREVISION

Add a commit revert patch for 10.x to keep HW accel working on Intel. cpm reported that his gen6 system lost HW accel upgrading from Mesa 17.0.4 to 17.1.0 and it was due to this commit. As I have no issue on 11.0, the feature check is catching some difference between 10.x and 11.x

In D10448#221651, @kwm wrote:

I can't comment on the qa.sh patch, so leave that to portmgr@

Just curious, how did you get to the mesa-dri and mesa-libs names?

I will report back after run-time testing.

Unfortunately the differential is without full context so I cannot inline the comments pertaining to graphics/wayland/Makefile.

Terminate strings from sysctl and add header include guard for portability.

Improve platform support as suggested and drop DEBUG.

In D10448#219796, @johalun0_gmail.com wrote:

It is not the size of libwayland-egl that was the concern, rather that I expect some amount of complaints about Mesa depending on graphics/wayland. Since Xorg depends on Mesa, that would mean Xorg pulls in Wayland even without Xwayland installed. Maybe I am being overly cautious here, but "Why does Mesa depend on LLVM from ports when the same version is provided by the base system?" is a regularly recurring question, sometimes in the form of a complaint. Let's take a poll during the call today to see what the group thinks the option's default state should be.

Hmm I see. Do you really need Wayland for Mesa to build Wayland platform? Can't find any dependency in Mesa makefiles. Even if it depends on it, isn't that only for building? If Xorg would pull in all Wayland stuff (libudev-devd/epoll etc) I can understand your concern and why many people would object.

In D10448#219771, @johalun0_gmail.com wrote:

That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.

When I install X I get a bunch of legacy crap I never use. At least a couple of Wayland files is in the direction we're going and won't hog that much disk space.. Personally I don't see the harm.

• libwayland-egl 4,632 bytes
• libgbm slightly larger size?
• Possibly some header files and a bigger library for GTK.

Are the ones I can think of that you'd get. The rest is in wayland & deps and the compositors.

Xwayland is the big one and that's already a separate port.

In D10508#219733, @jbeich wrote:

I'm a bit biased against DEBUG but the rest looks fine.

In D10448#219739, @johannes_brilliantservice.co.jp wrote:

• Can we have mesa-libs also generate libwayland-egl.so?

That is done when the WAYLAND option is enabled.

That means to use Wayland related stuff you still need to build your own ports? (meaning no 'pkg install weston' for those who want to try it)

That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.

This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.

I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.

Maybe we can split it up like xorg-server/xwayland. gtk30-wayland?

That would be ideal if possible. I do not know much about gtk30 so I cannot comment on the feasibility and will defer to kwm as the expert.

In D10448#219722, @johannes_brilliantservice.co.jp wrote:

Hey! Nice work on this.
I have a couple of suggestions that to make way for Wayland.

In Mesa:

• Can we have mesa-libs also generate libwayland-egl.so?

That is done when the WAYLAND option is enabled.

• Wayland also needs to be enabled with --with-egl-platforms flag (previosly in libGL Makefile.common)

Also done when the WAYLAND option is enabled.

• Enable DRI3 by default? (not really needed for wayland)

DRI3 support is already enabled at build time. There is an extra runtime switch due to EGL failing to fallback to DRI2 when the system doesn't support DRI3, i.e. stock FreeBSD. I hope that work-around will be short lived but there is not yet any response to the ticket I opened upstream so I might have to be the one to fix it.

Outside of Mesa I would like to

• Enable wayland backend by default in gtk30.
• Enable Xwayland in xorg-server

We have x11-servers/xwayland now. Is there something missing or not enabled in the build?

This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.

I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.

Revise patch-lib_CL_devices_cpuinfo.c

Update based on feedback in the PR.

Replace direct reference to libGL with USE_GL=gl in science/iboview

Refresh patch due to changes in MOVED

Trim obsolete USES=libtool:keepla