Add pkgconfig data for libraries implemented so far #86
Conversation
This preserves the names from Mesa's gl, glesv1_cm, and glesv2 pkgconfig data, and for compatibility with that, gl.pc gives you libGL. If newer applications want to explicitly depend on libGLX and the appropriate rendering API they can ask for the new pkgconfig names.
|
should there be an |
No, libglvnd doesn't implement EGL yet. |
|
I think to really land this we need to also install |
|
That's a good question, actually: Should we install the normal GL/GLES/GLX headers from the libglvnd tree? Installing the header files from the same place as the corresponding libraries kinda makes sense, but they're likely to become out of date pretty quickly. Khronos's subversion repository is arguably the upstream version of those, but it doesn't include any packaging-related stuff. It's also missing gl.h, and I think there were a couple problems with the GLX headers last time I looked, but that's all fixable. |
|
Agreed the headers should really come from Khronos somehow, and we really should solve the lack-of-a-canonical-gl.h issue there. We've been trying to assert that Khronos and/or distros are the right source for these rather than install our chronically out of date versions from our driver installer, and I doubt glvnd would be drastically better at staying in sync. |
|
I tend to see GLVND as a bit more than just a frontend/loader/dispatch library. IMHO it comes as "the one and only thing you need to create GL applications against". Requiring one to have mesa, in order to get the headers (compile time deps.) and GLVND for the libraries (link time deps.) does sound a bit fishy. And yes, distributions tend to ship mesa's headers as Khronos does not provide gl.h or glx.h, plus I believe there's been an occasion or two where the public headers were out of date wrt the internal copy. Obviously if vendors have specific needs (for example mesa has eglmesaext.h) they will ship only them. If there are any concerns about things going out of date, one can setup a script that fetches/updates things ;-) |
The headers Khronos does provide are generated from public scripts and the registry xml at this point. It's straightforward to add a gl.h template at least (and I've opened a Khronos bug about it). |
|
If Khronos can provide the full set of headers (just like they do for OpenCL) that'll be even better. |
|
From a packager's point of view, I would really like this to get integrated – is there something in particular blocking it? I believe almost all packages should be built against vendor-neutral files only, including headers, pkg-config and libs. EDIT: BTW, there is EGL support on master already, apparently. |
|
I'll need to update this to include the EGL headers, but other than that, I'd be fine with adding the pkgconfig files for the various OpenGL libraries to libglvnd. I think I've got a modified version of the header generation script somewhere that'll generate the old gl.h file. The main question is whether there's a good way to keep the libglvnd files up-to-date with the upstream Khronos XML files. It's easy enough to go grab the updated XML files and check in copies to libglvnd, but remembering to do that periodically is the problem. Also a more minor question, should we also add a configure option for whether or not to include the GL headers? If you're building and installing libglvnd manually on an existing system, then you might not want to overwrite the files that the package manager's installed. |
|
Isn't the overwriting situation similar for the libraries as well? I'd assume that "users" either use a custom prefix or they know what they're doing (even separate prefixes for headers, libs etc. are possible already, I think, as usual with auto-tools). |
|
I tried building wlroots with this and got a -lEGL undefined error. I need to get back to my machine to get the exact output. |
There was a problem hiding this comment.
A few changes to the names and descriptions; I think the version numbers should also relate to the actual APIs being exposed, rather than just being the glvnd package version. Mesa has already gone down the route of exposing its package version, and that was definitely a mistake.
| libdir=@libdir@ | ||
| includedir=@includedir@ | ||
|
|
||
| Name: gl |
There was a problem hiding this comment.
| Name: gl | |
| Name: glesv1_cm |
| libdir=@libdir@ | ||
| includedir=@includedir@ | ||
|
|
||
| Name: openg |
There was a problem hiding this comment.
| Name: openg | |
| Name: opengl |
| includedir=@includedir@ | ||
|
|
||
| Name: openg | ||
| Description: libglvnd OpenGL library |
There was a problem hiding this comment.
| Description: libglvnd OpenGL library | |
| Description: OpenGL (without GLX) headers and interface |
| includedir=@includedir@ | ||
|
|
||
| Name: glx | ||
| Description: libglvnd GLX library |
There was a problem hiding this comment.
| Description: libglvnd GLX library | |
| Description: GLX library and headers |
| includedir=@includedir@ | ||
|
|
||
| Name: gles2 | ||
| Description: libglvnd OpenGL ES v2+ library |
There was a problem hiding this comment.
| Description: libglvnd OpenGL ES v2+ library | |
| Description: OpenGL ES v2/v3 library and headers |
| includedir=@includedir@ | ||
|
|
||
| Name: gl | ||
| Description: libglvnd OpenGL ES v1 library |
There was a problem hiding this comment.
| Description: libglvnd OpenGL ES v1 library | |
| Description: OpenGL ES-CM v1 library and headers |
| includedir=@includedir@ | ||
|
|
||
| Name: gl | ||
| Description: libglvnd legacy OpenGL library |
There was a problem hiding this comment.
| Description: libglvnd legacy OpenGL library | |
| Description: Legacy OpenGL and GLX library and headers |
|
I think |
|
Seeing as the patch doesn't apply cleanly, and I wanted something that works so wlroots-git was happy, I rebased it: |
|
@fooishbar if @nwnk doesn't answer, I can propose a new PR with your suggestions. |
|
What @evelikov and @fooishbar said here are what I want to see happening as well. The same package/project must provide all of library, headers, and pkg-config files together to allow building software against them. That is what people using them expect, and anything else is just confusing. I also agree that pkg-config files for APIs (EGL, OpenGL, GL ES 1, GL ES 2, etc.) should be versioned by the API version they provide, not by the project version, because users are using e.g. GL ES 2, not libglvnd or Mesa per se. I'm just slightly worried that Mesa has set a precedent here for these |
|
I'd agree with @fooishbar's changes to make the pkg-config names match the library names. That also gives them the best chance to work as a drop-in replacement for Mesa's pkg-config files. I'd also agree that the version number should match the API version that they expose, not the package version of libglvnd or Mesa itself. If you're building a program that uses GL/GLX/EGL, then you don't care about the build-time version of Mesa. You might care about what set of stuff is declared in the header files, but the OpenGL headers already use macros to indicate which versions and extensions are declared. Changing the version number might require updating other projects that look for a specific version number, but I would suspect that those cases are very rare for the reasons above. Besides, if we're moving the pkg-config files to libglvnd, then it wouldn't be practical to track Mesa's version number in them, so we'd have to change the version number anyway. |
|
For reference, the version numbers that we'd want to use for each library are:
|
|
Hello, Is there any idea when this will get merged as when mesa dropped those files out of their packages we on Arch linux have been unable to build GNOME mutter. |
|
Rebased and attempted to address comments and suggested changes: This was just copy and pasting; I have no idea what I'm doing. I only rebased this PR so my packages would properly build again. Hopefully this is correct functionality-wise and can be useful to others that require it. |
you missed changes to src/GLX/Makefile.am and src/OpenGL/Makefile.am |
Fixed. Must have forgotten to add them when generating the commit for diffing or simply overlooked. |
|
What about the header files, though? If packagers have to grab those from Mesa and/or Khronos, then just getting the pkg-config files from libglvnd instead of Mesa doesn't seem helpful. |
I think it would be helpful to ship the header files as well. If you're shipping Anyway, even without the headers, one of the things pkg-config does is to tell build systems where to find libraries to link to, without having to hardcode |
|
With https://gitlab.freedesktop.org/mesa/mesa/commit/1a25980c469b38d2c6456344fe538ad1bcb47f63 libglvnd will also need to provide |
|
Updated patch to provide egl.pc : |
|
Thank you @terencode, however that patch does not apply for me: Shuffling around the order of the diffs fixes stuff. Here is what worked for me: https://gentz.rocks/files/1563985448/Add-pkgconfig-data-for-libraries-implemented-so-far.patch |
|
@zegentzy Oups, I don't know what I'm did wrong with github gist so here is the actual file: https://github.com/NVIDIA/libglvnd/files/3428633/Add-pkgconfig-data-for-libraries-implemented-so-far.txt |
|
Kyle, can you please commit this? As far as I know, this is the only thing I need in Gentoo in order to ship libglvnd by default. |
|
One thing to note is the version the pkgconfig files will provide will be the same as libglvnd with the current code, which will make them have a lower version than when it was shipped with mesa. For example JHBuild expects egl.pc and glesv2.pc to be respectively at 10.1.3 and 9.2 but they are all at 1.1.1 |
Easily solvable once this pull request is finally committed. Those versions of Mesa are so old that the version check is next to useless. |
|
@kbrenneman @nwnk |
|
I've got the new .pc files in pull request #179. The main difference from the patches here is that I changed the version numbers to match the API versions instead of the package version, and I added the header files to the installation. |
|
I've got the changes checked in now as #179, so closing this one. |
This preserves the names from Mesa's gl, glesv1_cm, and glesv2 pkgconfig
data, and for compatibility with that, gl.pc gives you libGL. If newer
applications want to explicitly depend on libGLX and the appropriate
rendering API they can ask for the new pkgconfig names.