[Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

Dylan Baker dylan at pnwbakers.com
Fri Jun 15 16:46:32 UTC 2018


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180615/649dd3f5/attachment-0001.sig>


More information about the mesa-dev mailing list