Re: Driver OPTIONS for graphics/mesa-*

 Hello Gleb,

On Tue, 19 May 2026 16:49:03 +0300
Gleb Popov <[email protected]> wrote:

> Hey x11@ veterans.
> 
> While working through Mesa 25 [1] and 26 [2] updates I stumbled upon
> the following problem
> regarding OPTIONS handling. mesa-libs and mesa-dri are packages built
> from the same codebase and we must take care to build both ports with
> matching Meson options.
> 
> For example, the current version of graphics/mesa-libs passes
> -Dgallium-drivers="r300" to Meson unconditionally, 

 IIRC this is because some stuff in -libs needs a dri driver being
built, doesn't matter which ones. So, again iirc, I've chosen the
smallest one to not add too much time to the build.

> while
> graphics/mesa-dri allows for changing gallium-drivers via the OPTIONS
> mechanism. This worked so far, but starting with Mesa 25 upstream
> followed the "megalib" approach, which made Meson options more
> entangled. It requires building more gallium drivers in mesa-libs and
> it is still possible to mess things up by selecting different PLATFORM
> options.
> 
> We can try to stick with the current approach, like it is done in [1],
> or make both graphics/mesa-libs and graphics/mesa-dri share the same
> set of OPTIONS like it is done in [2]. Or we can just remove
> all these OPTIONS altogether, which I like the most. In future, once
> we get subpackages, these two ports can be merged into one and OPTIONS
> reinstated, which would be an ideal solution.
> 
> What are your thoughts on this?
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294948
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294957
> 

 The main problem is that mesa is, and was never meant to be built in a
splitted way like we do. We've done that "back then (tm)" because of
the lack of subpackages like any linux distrib.
 Having a big mesa package is a no-go for me, and this is why I've
never updated mesa since a long time as some new build option make this
very problematic.
 The real solution is having a graphics/mesa port with subpackages, in
the meantime I honestly don't know what are our best solutions.

 Cheers,

-- 
Emmanuel Vadot <[email protected]> <[email protected]>