[Mesa-dev] [Bug 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110141

Eric Engestrom <fdo-bugs at engestrom.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #2 from Eric Engestrom <fdo-bugs at engestrom.ch> ---
I'm really tempted to close this as NOTOURBUG, as it's the provider of a
library that should claim to provide it (ie. GLVND in this case), but if I
understand correctly, glesv2.pc isn't actually used for its contents but rather
just as a "does this file exist" check.

The thing I don't understand though is: why?
What does mutter or wlroots do with this information?

In a non-GLVND environment, you compile Mesa with things enabled or not, and
you get .so and .pc files that tell you what you have and can use, but in a
GLVND environment this information would have to be per-vendor, which a generic
`gles2.pc` file cannot give.

Say, for instance, that you have the proprietary NVIDIA driver and Mesa on your
system.
NVIDIA provides GLES 1 & 2, and Mesa is compiled with only GLES 1.
You won't have gles2.pc, but GLVND provides libGLESv2.so, and it would be able
to provide an actual context thanks to the NVIDIA driver.
And what about gles1.pc, should NVIDIA or Mesa provide this file? They wouldn't
be able to both provide it, so how would you decide who does?

So again, I really don't understand the meaning that's given to "does gles2.pc
exists?". Am I missing something?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190326/44aa375e/attachment.html>