Downstream packaging best practices in combination with Vulkan-Headers about vulkan-loader HOT 5 OPEN

Apologies for the delayed response.

To reiterate the problem to say what I think the 'problem' being asked is: Vulkan-Headers lacks a .pc file, Vulkan-Loader provides on for itself and Vulkan-Headers, and there is no clear solution package managers should employ for packaging both repos.

I naively thought making the loader depend on the headers was the best option, but then I remembered that vulkan-loader is for running while vulkan-headers is for building. All Vulkan apps need the loader to run, only people building vulkan apps need the headers. It is very confusing to see the headers be a requirement for a binary only package. That said, apps that link to the loader do need both headers & binary. Debian having a libvulkan1 (loader) and a libvulkan1-dev (headers) packages makes sense to me as a user. Whether that workflow is a lot of extra steps for package maintainers I do not know.

I really am unable to say which is the 'best' solution. Part of the issue is inconsistently providing vulkan.pc - maybe Vulkan-Headers should provide its own so package maintainers can use those. But I do not know enough of the pkg-config workflow or best practices to really offer a strong recommendation for any of the above solutions.

from vulkan-loader.

Thinking things through, I believe the root of the cause is the 2018 split of the Vulkan-LoaderAndValidationLayers "monorepo" into its constituent parts (loader, headers, validation layers, tools). The archived repo has https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/loader/vulkan.pc.in which is the origin of vulkan.pc. Back when there was only one 'repo' to package.

I believe there needs to be a vulkan-loader.pc and a vulkan-headers.pc, and deprecate vulkan.pc (which attempts to do both things, and does so poorly).

from vulkan-loader.

Debian having a libvulkan1 (loader) and a libvulkan1-dev (headers) packages makes sense to me as a user. Whether that workflow is a lot of extra steps for package maintainers I do not know.

This is the runtime vs buildtime split that Linux distros tend to do. In those cases, the runtime doesn't need a pkgconfig file, because pkgconfig is only used for build-time dependency tracking.

So it sounds to me like the pc file should just be moved into the headers repository.

Does anyone ever build against the loader but without the headers?
In that case it might make sense to add a vulkan-loaders.pc.

I don't think building against the headers without the loader is possible because it involves linking against the library provided by the loader.
And then I'd advocate keeping vulkan.pc instead of adding a new headers pkgconfig file to (a) not break all consumers and (b) make it easy to find, because with a libthing.so I'd expect a thing.pc pkgconfig file.

from vulkan-loader.

I don't think building against the headers without the loader is possible because it involves linking against the library provided by the loader.

There is no requirement for apps to link to the loader when building. They can set VK_NO_PROTOTYPES and load all functions at runtime (or use a library like volk which does that for you).

Hence why its a good reason to have a separate vulkan-loader.pc and vulkan-headers.pc. If you only need headers to build, just use vulkan-headers.pc. If you are linking to the loader, then you need vulkan-loader.pc and then to get the headers use vulkan-headers.pc. This mirrors the fact that the repo is Vulkan-Loader now as well.

I advocate not changing vulkan.pc, as breaking users by changing it (to remove the headers) is bad. Keeping it around but mark it as deprecated would be idea.

from vulkan-loader.

That makes sense.

I think it's not the default and the default is what vulkan.pc does?
In that case keeping vulkan.pc around and not deprecating it would be better I think. Even if it just requires both the loaders and headers pc file.

from vulkan-loader.