https://bugs.freedesktop.org/show_bug.cgi?id=94086
--- Comment #2 from Chuck Atkins <chuck.atk...@kitware.com> ---
> Fwiw I'd rather have a configure error, if one tries to build conflicting
> (at install time) files.
The glx options are implemented differently than the osmesa ones, even though
they try to accomplish the same thing. The osmesa options translate to "enable
classic osmesa" or "enable gallium osmesa", but the glx options, on the other
hand, translate to "enable glx period, (defaulting to dri-glx)" and "use
xlib-glx instead of dri-glx".
After digging through the code a bit more, I believe my patch is perhaps not
the right approach. Is "classic" synonymous with dri? There seems to
currently be 3 GLX implementations: dri-glx in src/glx, classic-xlib-glx in
src/mesa/x11, and gallium-xlib-glx in src/gallium/state_trackers/glx/xlib.
What is not clear to me now is under what situation should each of these
implementations actually be built. Currently both src/mesa/x11 and
state_trackers/glx/xlib are getting built, which is the root of the problem I'm
trying to address. So what are the conditions then that src/mesa/x11 should be
built vs when src/gallium/state_trackers/glx/xlib ? Given that I can fix the
patch accordingly.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
