**** BEGIN LOGGING AT Wed Dec 01 02:59:56 2021
Dec 01 15:13:30 <mort> Which package provides EGL/eglmesaext.h? ...And is there a general way to answer these kinds of questions in the future?
Dec 01 16:02:07 <rburton> mort: assuming you've built something that provides that, oe-pkgdata-util find-path will tell you
Dec 01 16:04:10 <mort> find-path eglmesaext.h says it's unable to find any package producing that path, so I suppose I haven't built any packages which provides it
Dec 01 16:05:14 <rburton> there's no central index online as your setup will be different
Dec 01 16:05:33 <rburton> i'd guess mesa from the filename
Dec 01 16:06:27 <mort> I can't depend on mesa (because virtual/whatever is set to mesa-gl), and mesa-gl doesn't produce it
Dec 01 16:06:39 <rburton> so what is your EGL provider?
Dec 01 16:07:03 <mort> i tried a 'find build/tmp -name eglmesaext.h' and it only exists in recipe sysroots for -native packages, and then it exists in mesa
Dec 01 16:07:07 <mort> but nothing apparently installs it
Dec 01 16:07:14 <mort> I don't know how I check my EGL provider is
Dec 01 16:07:33 <rburton> if you've told it to only build mesa-gl, then you don't get EGL
Dec 01 16:07:53 <mort> I kind of need EGL though, and DISTRO_FEATURES includes egl
Dec 01 16:07:56 <rburton> if you want egl, don't use mesa-gl
Dec 01 16:08:05 <rburton> or bring another GL stack that has EGL
Dec 01 16:08:24 <mort> I depend on virtual/egl tho, and that works
Dec 01 16:08:36 <rburton> the point of mesa-gl is that you use it when you have a binary driver that does EGL/GLES, but you need 'big' GL in software for compat (which is mesa-gl)
Dec 01 16:09:36 <rburton> if you want EGL why did you set the virtual thing to mesa-gl?
Dec 01 16:09:41 <tlwoerner> khem: ready to go?
Dec 01 16:10:08 <mort> I didn't set the virtual thing to mesa-gl
Dec 01 16:10:38 <mort> it is set to mesa-gl, but it's entirely possible that's incorrect
Dec 01 16:10:56 <mort> ah, it's PREFERRED_PROVIDER_virtual/libgl that's set to mesa-gl
Dec 01 16:11:06 <mort> that looks completely reasonable but I don't understand why that prevents me from depending on mesa
Dec 01 16:11:37 <rburton> you'd only do that if you had a second GL stack that provided EGL/GLES
Dec 01 16:11:44 <mort> which I do
Dec 01 16:13:00 <mort> but the second EGL stack doesn't provide a eglmesaext.h
Dec 01 16:13:13 <mort> and, quoting emersion, "some exts were missing from the khronos header at some point, so the mesa one was required" -- so it would be really useful to have eglmesaext.h
Dec 01 16:13:52 <rburton> tell the provider of your EGL stack that
Dec 01 16:14:00 <mort> why can't I just get the header from mesa
Dec 01 16:14:13 <mort> it's in the mesa repo
Dec 01 16:14:22 <rburton> why would mesa provide random EGL headers for an entirely different GL stack
Dec 01 16:14:30 <mort> idk, but apparently they do?
Dec 01 16:14:40 <mort> it's just a few typedefs
Dec 01 16:15:16 <rburton> i mean why would our mesa recipe ship headers that are expected to be used with other stacks
Dec 01 16:15:40 <rburton> your BSP turned off EGL in mesa, and provides its own.  it's not compatile with mesa, and that's not mesa's fault.
Dec 01 16:16:41 <rburton> its a three line bbappend to make mesa-gl ship this header too, but that's horrible
Dec 01 16:17:19 <mort> so eglmesaext is just for a mesa implementation of egl, I suppose that makes sense
Dec 01 16:18:06 <mort> welp
Dec 01 16:18:20 <mort> I can't say the vendor has done anything wrong, since it's apparently the khronos headers which were missing the extensions
Dec 01 16:19:11 <rburton> some vendors ship the mesa headers as they're defacto standard, if not the actual standard
**** ENDING LOGGING AT Thu Dec 02 02:59:56 2021