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

Dylan Baker dylan at pnwbakers.com
Fri Jun 15 17:41:20 UTC 2018

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?

-------------- 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/75510de0/attachment.sig>

More information about the mesa-dev mailing list