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