Quoting Kyle Brenneman (2018-06-15 10:23:24) > On 06/15/2018 10:46 AM, Dylan Baker wrote: > > Quoting Kyle Brenneman (2018-05-30 06:18:27) > >> On 05/29/2018 12:04 PM, Adam Jackson wrote: > >>> On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote: > >>>> Quoting Adam Jackson (2018-05-29 06:50:46) > >>>>> GL_LIB expands to GLX_mesa, but applications should not link against > >>>>> that. -lGL is never wrong, just hardcode it. > >>>> Actually.... There is this really stupid option in the autotools build > >>>> called > >>>> --gl-lib-name. We should remove that. > >>>> > >>>> Emil and I had also discussed that glvnd should provide the gl.pc file > >>>> when used > >>>> instead of mesa. It appears he never got around to that, but it seems > >>>> like a > >>>> useful thing to do. > >>> https://github.com/NVIDIA/libglvnd/pull/86 > >>> > >>> Branch is a bit stale but better than reinventing everything. > >>> > >>> Part of the reason I didn't get much further on that is the question of > >>> distributing the _headers_. It would be a bit awkward if glvnd provided > >>> the library you link to but not the headers defining its interface - > >>> though, I guess no more awkward than the current situation. At any rate > >>> glvnd doesn't install any, and there's no way to generate <GL/gl.h> > >>> from the Khronos scripts at the moment (it's assumed to be a platform > >>> implementation detail, and the version in Mesa is just handcoded > >>> history). > >>> > >>> - ajax > >>> > >> Yeah, the headers versus libraries question is what makes it awkward. > >> Libglvnd provides the libraries that an application links against, but > >> the header files are basically from the Khronos repository. Treating > >> libglvnd as the source for the libraries and the Khronos tree as the > >> source for the headers would seem to be the cleanest option, but the > >> pkg-config files would have to include the paths to both. > >> > >> Now that I think about it, though, since the Khronos registry is on > >> Github now instead of SVN, maybe a git submodule would work? > >> > >> -Kyle > >> > > Could we make a package for the headers separate from glvnd or mesa, with > > it's > > own pkg-config (basically just a fork with a pkg-config)? Then mesa and > > glvnd > > could rely on that package? Or maybe Khronos would be willing to accept > > something > > upstream? > > > > I don't know what the feasibility of either is, I'm just throwing out ideas. > > > > Dylan > > > The Khronos repository basically is a package for the headers. The > challenge is that the pkg-config file has to specify an include path and > a library path. The include path depends on where you put the header > files (which are in the Khronos repository), but library path depends on > how you configure libglvnd.
But it could declare the library and then depend on another pkg-config that has the include path, right? So we could have a pkg-config for 'khronos-gl-headers' and a pkg config for 'libgl', and the libgl could declare a requires khronos-gl-headers. That would allow both libglvnd and mesa to avoid ever shipping the headers. Or would that just be too much headache? Dylan
signature.asc
Description: signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
