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?
• Wayland also needs to be enabled with --with-egl-platforms flag (previosly in libGL Makefile.common)
• Enable DRI3 by default? (not really needed for wayland)

Outside of Mesa I would like to

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

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.

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.

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

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?

About GTK3 I will have to look at that. I'm not sure yet how to tackle that since there is also the X backend to consider.

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.

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

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.

P.S. I cleaned some of the cruft from the Xorg build, e.g. dropped a handful of legacy libs/extensions that weren't used anymore and pruned the default options in x11-drivers/xorg-drivers, but if there is other truly legacy crap getting installed somewhere down the line from x11/xorg-minimal then please tell me what else you think should not be included in minimal (of course x11/xorg will install almost everything).

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

The WAYLAND option adds graphics/wayland to LIB_DEPENDS because both gbm and libEGL link to libwayland-client.so and libwayland-server.so when the wayland platform is enabled.

To illustrate, I just did a build with the WAYLAND option enabled to compare output from ldd.

WAYLAND OFF
/usr/local/lib/libgbm.so:

libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x80120b000)
libm.so.5 => /lib/libm.so.5 (0x801436000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x801660000)
libthr.so.3 => /lib/libthr.so.3 (0x801871000)
libc.so.7 => /lib/libc.so.7 (0x800824000)

/usr/local/lib/libEGL.so:

libthr.so.3 => /lib/libthr.so.3 (0x80122d000)
libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x801454000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801655000)
libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x801997000)
libxcb-xfixes.so.0 => /usr/local/lib/libxcb-xfixes.so.0 (0x801b9b000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x801da2000)
libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x801fc7000)
libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x8021c9000)
libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x8023cb000)
libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x8025d1000)
libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x8027d2000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8029dd000)
libm.so.5 => /lib/libm.so.5 (0x802c08000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x802e32000)
libc.so.7 => /lib/libc.so.7 (0x800824000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x803043000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x803246000)

WAYLAND ON
/usr/obj/usr/ports/graphics/mesa-libs/work/stage/usr/local/lib/libgbm.so:

libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x80120d000)
libm.so.5 => /lib/libm.so.5 (0x801438000)
libwayland-client.so.0 => /usr/local/lib/libwayland-client.so.0 (0x801662000)
libwayland-server.so.0 => /usr/local/lib/libwayland-server.so.0 (0x801873000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x801a89000)
libthr.so.3 => /lib/libthr.so.3 (0x801c9a000)
libc.so.7 => /lib/libc.so.7 (0x800824000)
libffi.so.6 => /usr/local/lib/libffi.so.6 (0x801ec1000)
libepoll-shim.so.0 => /usr/local/lib/libepoll-shim.so.0 (0x8020c8000)
librt.so.1 => /usr/lib/librt.so.1 (0x8022cb000)

/usr/obj/usr/ports/graphics/mesa-libs/work/stage/usr/local/lib/libEGL.so:

libthr.so.3 => /lib/libthr.so.3 (0x801233000)
libX11-xcb.so.1 => /usr/local/lib/libX11-xcb.so.1 (0x80145a000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x80165b000)
libxcb-dri2.so.0 => /usr/local/lib/libxcb-dri2.so.0 (0x80199d000)
libxcb-xfixes.so.0 => /usr/local/lib/libxcb-xfixes.so.0 (0x801ba1000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x801da8000)
libxcb-dri3.so.0 => /usr/local/lib/libxcb-dri3.so.0 (0x801fcd000)
libxcb-present.so.0 => /usr/local/lib/libxcb-present.so.0 (0x8021cf000)
libxcb-sync.so.1 => /usr/local/lib/libxcb-sync.so.1 (0x8023d1000)
libxshmfence.so.1 => /usr/local/lib/libxshmfence.so.1 (0x8025d7000)
libwayland-client.so.0 => /usr/local/lib/libwayland-client.so.0 (0x8027d8000)
libwayland-server.so.0 => /usr/local/lib/libwayland-server.so.0 (0x8029e9000)
libgbm.so.1 => /usr/local/lib/libgbm.so.1 (0x802bff000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x802e0a000)
libm.so.5 => /lib/libm.so.5 (0x803035000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x80325f000)
libc.so.7 => /lib/libc.so.7 (0x800824000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x803470000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x803673000)
libffi.so.6 => /usr/local/lib/libffi.so.6 (0x803878000)
libepoll-shim.so.0 => /usr/local/lib/libepoll-shim.so.0 (0x803a7f000)
librt.so.1 => /usr/lib/librt.so.1 (0x803c82000)

To illustrate, I just did a build with the WAYLAND option enabled to compare output from ldd.

Hmm, that sucks. This is a big negative about the ports system... How far away is 'flavors'? :)

There is a review for flavours but it seems only to be a simple version and only for python yet.

About not enabling wayland by default, I can understand that people don't really like the extra depends of wayland in the mesa-libs port, if they don't use wayland itself.
Personaly I don't really see a problem, wayland itself is tiny, almost non existing, compared to llvm.
Wayland Flat size: 1.44MiB, llvm39 Flat size: 1.08GiB.

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.

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.

Ideally, those would be built as a single port which produces two packages, the drivers and the libraries. The root name is mesa because that's the name upstream and what user's are most likely to look for. I had also considered mesa-drivers but the drivers retained the dri suffix since that is what the port was called previously so it remains easier to find for everyone familiar with that name. It seemed natural to use the libs suffix for the libraries.