include/KHR/khrplatform.h conflicts with mesa-libs

[yurivict]

The file include/KHR/khrplatform.h that your install conflicts with the package mesa-libs.

You should only install files under include/glad.

[Dav1dde]

Which install conflicts? Generated glad files shouldn't be installed globally on your system, it also doesn't provide an out of the box way to do that.

The provided khrplatform.h just exists for convenience and if it is already provided by your platform you can safely delete it. Even though you can delete it, you should still bundle it with your project, the point of glad is to be configurable and platform independent at runtime and compiletime.

[yurivict]

cmake creates the 'install' target, and it installs the following files:

include/KHR/khrplatform.h
include/glad/glad.h
lib/cmake/glad/gladConfig.cmake
lib/cmake/glad/gladConfigVersion.cmake
lib/cmake/glad/gladTargets-%%CMAKE_BUILD_TYPE%%.cmake
lib/cmake/glad/gladTargets.cmake
lib/libglad.so

The following cmake options are set to ON: GLAD_INSTALL BUILD_SHARED_LIBS GLAD_REPRODUCIBLE

[Dav1dde]

You should not use this to install globally, if at all install to a project directory.
Also not all platforms provide khrplatform.h which just would break it for everyone of these platforms.

What are you trying to do, why do you want to install glad generated files?

PS: The shared library is another thing that should not be installed/used globally, heck even when integrated in your build system you should just statically link and call it a day.

[yurivict]

I created the FreeBSD port on 2019-06-09. I don't remember the reason now, perhaps it was for a dependency of some other port/package.

Two other distros have packages for glad too: https://repology.org/project/glad/versions

[ghost]

It would seem to me that the generator would be an appropriate thing to pack into a distro.

…

On March 29, 2020 5:18:12 PM MDT, ***@***.***" ***@***.***> wrote: I created the FreeBSD port on ```2019-06-09```. I don't remember the reason now, perhaps it was for a dependency of some other port/package. Two other distros have packages for ```glad``` too: https://repology.org/project/glad/versions -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #260 (comment)

[Dav1dde]

As @fluffrabbit said the Python program would be a good thing to package (that's how the conan and vcpkg do it as well).

If other projects have glad generated files as an open dependency, you could still install glad files globally you'd just have to either install the files manually not through cmake or deleting the khrplatform before installing.

But if you're installing glad you'd need to specify what specification and API it is (GL, GLES, GLX) and what version with the compatibility profile and all extensions. But even then providing a shared library of glad just doesn't make sense, a static library I could see out of convenience but even that is questionable.

[Dav1dde]

Feel free to reopen/comment if there is anything else you need to know or is unclear or you think should be changed.