pkgconfig: Fix gl.pc when glvnd is enabled

Submitted by Adam Jackson on May 29, 2018, 1:50 p.m.

Details

Message ID 20180529135046.2491-1-ajax@redhat.com
State New
Headers show
Series "pkgconfig: Fix gl.pc when glvnd is enabled" ( rev: 1 ) in Mesa

Not browsing as part of any series.

Commit Message

Adam Jackson May 29, 2018, 1:50 p.m.
GL_LIB expands to GLX_mesa, but applications should not link against
that. -lGL is never wrong, just hardcode it.

Signed-off-by: Adam Jackson <ajax@redhat.com>
---
 src/mesa/gl.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
index 181724b97b..8c7b7da8d7 100644
--- a/src/mesa/gl.pc.in
+++ b/src/mesa/gl.pc.in
@@ -7,7 +7,7 @@  Name: gl
 Description: Mesa OpenGL library
 Requires.private: @GL_PC_REQ_PRIV@
 Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -l@GL_LIB@
+Libs: -L${libdir} -lGL
 Libs.private: @GL_PC_LIB_PRIV@
 Cflags: -I${includedir} @GL_PC_CFLAGS@
 glx_tls: @GLX_TLS@

Comments

On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
> GL_LIB expands to GLX_mesa, but applications should not link against
> that. -lGL is never wrong, just hardcode it.

Agreed, and Archlinux has had this patch since basically forever:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa

> 
> Signed-off-by: Adam Jackson <ajax@redhat.com>

Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Tested-by: Eric Engestrom <eric.engestrom@intel.com>

> ---
>  src/mesa/gl.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
> index 181724b97b..8c7b7da8d7 100644
> --- a/src/mesa/gl.pc.in
> +++ b/src/mesa/gl.pc.in
> @@ -7,7 +7,7 @@ Name: gl
>  Description: Mesa OpenGL library
>  Requires.private: @GL_PC_REQ_PRIV@
>  Version: @PACKAGE_VERSION@
> -Libs: -L${libdir} -l@GL_LIB@
> +Libs: -L${libdir} -lGL
>  Libs.private: @GL_PC_LIB_PRIV@
>  Cflags: -I${includedir} @GL_PC_CFLAGS@
>  glx_tls: @GLX_TLS@
> -- 
> 2.17.0
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 29 May 2018 at 15:17, Eric Engestrom <eric.engestrom@intel.com> wrote:
> On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
>> GL_LIB expands to GLX_mesa, but applications should not link against
>> that. -lGL is never wrong, just hardcode it.
>
> Agreed, and Archlinux has had this patch since basically forever:
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa

Ugh. There's also this patch from February doing a similar thing:
https://patchwork.freedesktop.org/patch/206547/

Cheers,
Daniel
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.

Dylan

> 
> Signed-off-by: Adam Jackson <ajax@redhat.com>
> ---
>  src/mesa/gl.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
> index 181724b97b..8c7b7da8d7 100644
> --- a/src/mesa/gl.pc.in
> +++ b/src/mesa/gl.pc.in
> @@ -7,7 +7,7 @@ Name: gl
>  Description: Mesa OpenGL library
>  Requires.private: @GL_PC_REQ_PRIV@
>  Version: @PACKAGE_VERSION@
> -Libs: -L${libdir} -l@GL_LIB@
> +Libs: -L${libdir} -lGL
>  Libs.private: @GL_PC_LIB_PRIV@
>  Cflags: -I${includedir} @GL_PC_CFLAGS@
>  glx_tls: @GLX_TLS@
> -- 
> 2.17.0
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 29 May 2018 at 15:29, Daniel Stone <daniel@fooishbar.org> wrote:
> On 29 May 2018 at 15:17, Eric Engestrom <eric.engestrom@intel.com> wrote:
>> On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
>>> GL_LIB expands to GLX_mesa, but applications should not link against
>>> that. -lGL is never wrong, just hardcode it.
>>
>> Agreed, and Archlinux has had this patch since basically forever:
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa
>
> Ugh. There's also this patch from February doing a similar thing:
> https://patchwork.freedesktop.org/patch/206547/
>
Almost s/similar/better/ ;-)

Unless I've missed something handful of the patches are still
unreviewed and applicable as-is.
Would have pushed the lot (with the cosmetics spotted by Dylan) yet
last time last few times there were plenty of unhappy people.

You know unreviewed being and all :-\
-Emil
On Tue, 2018-05-29 at 18:35 +0100, Emil Velikov wrote:
> On 29 May 2018 at 15:29, Daniel Stone <daniel@fooishbar.org> wrote:
> > On 29 May 2018 at 15:17, Eric Engestrom <eric.engestrom@intel.com> wrote:
> > > On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
> > > > GL_LIB expands to GLX_mesa, but applications should not link against
> > > > that. -lGL is never wrong, just hardcode it.
> > > 
> > > Agreed, and Archlinux has had this patch since basically forever:
> > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa
> > 
> > Ugh. There's also this patch from February doing a similar thing:
> > https://patchwork.freedesktop.org/patch/206547/
> > 
> 
> Almost s/similar/better/ ;-)
> 
> Unless I've missed something handful of the patches are still
> unreviewed and applicable as-is.
> Would have pushed the lot (with the cosmetics spotted by Dylan) yet
> last time last few times there were plenty of unhappy people.

I put my name down as maintainer for src/glx/ and yet I don't get cc'd
on things...

That series has my:

Reviewed-by: Adam Jackson <ajax@redhat.com>

- ajax
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
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
Any movement on one of these solutions ending up in master and 18.1.x
anytime soon?

On Thu, 31 May 2018 at 05:09, Kyle Brenneman <kyle.brenneman@gmail.com>
wrote:

> 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
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
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.

The libglvnd tree probably does make the most sense: That's where the 
libraries are from, and so it should be the only thing you need to build 
and link an OpenGL application. It also has a copy of the GL header 
files that it uses to build. It could install those copies, but the 
challenge then is keeping libglvnd's copy of the header files up to date.

-Kyle
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
On 06/15/2018 11:41 AM, Dylan Baker wrote:
> 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
Using two separate packages and two separate pkg-config files might 
work, but it seems like it would be overly complicated for both app 
developers and distro packagers. Also, we'd ideally want whatever we 
come up with to be a drop-in replacement for the current pkg-config 
files from Mesa.

If we were to let libglvnd grab the headers from another package, 
though, I suppose I could set up libglvnd to install the GL headers, and 
then add a configure option to libglvnd to point it at a copy of the 
Khronos repository. At that point, though, you might as well just build 
and install libglvnd normally and manually overwrite the GL headers -- 
the new option doesn't add much.

-Kyle
Quoting Kyle Brenneman (2018-06-15 11:02:37)
> On 06/15/2018 11:41 AM, Dylan Baker wrote:
> > 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
> Using two separate packages and two separate pkg-config files might 
> work, but it seems like it would be overly complicated for both app 
> developers and distro packagers. Also, we'd ideally want whatever we 
> come up with to be a drop-in replacement for the current pkg-config 
> files from Mesa.
> 
> If we were to let libglvnd grab the headers from another package, 
> though, I suppose I could set up libglvnd to install the GL headers, and 
> then add a configure option to libglvnd to point it at a copy of the 
> Khronos repository. At that point, though, you might as well just build 
> and install libglvnd normally and manually overwrite the GL headers -- 
> the new option doesn't add much.
> 
> -Kyle
> 

My thought was either mesa and glvnd would agree that neither would ship headers
and both would rely on the new package. But it sounds like that would be too
much headache.

Dylan
On Fri, 2018-06-15 at 11:23 -0600, Kyle Brenneman wrote:

> 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.
> 
> The libglvnd tree probably does make the most sense: That's where the 
> libraries are from, and so it should be the only thing you need to build 
> and link an OpenGL application. It also has a copy of the GL header 
> files that it uses to build. It could install those copies, but the 
> challenge then is keeping libglvnd's copy of the header files up to date.

To be honest, that's something that needs better automation anyway.
Epoxy and Mesa want to track the xml updates closely too. I've set up
cron jobs in travis to check daily whether the xml has been changed, so
I'll at least get notifications:

https://travis-ci.org/nwnk/OpenGL-Registry
https://travis-ci.org/nwnk/EGL-Registry

It would be good to close the loop there and automate the process of
importing the XML, rebuilding, checking for ABI breaks...

- ajax