Downstream packaging best practices in combination with Vulkan-Headers

[lazka]

We have the problem that Vulkan-Loader contains the pkg-config file, which some project use for detecting how to build against vulkan, while the headers are in the separate https://github.com/KhronosGroup/Vulkan-Headers project. This results in downstream packages needing to do extra check for headers etc.

In Arch Linux for example loader and headers are separate packages, resulting in build issues:

mesonbuild/meson#7956

In MSYS2 we follow what Arch does, leading to the same issue:

mesonbuild/meson#13016

Some downstream projects work around that by manually checking for headers:

https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/3fc66d4525916b9301236a000a6ed03311ed25a7/render/vulkan/meson.build#L17-25

In Debian the packages are built together and the development files are split out into a separate combined package (so the .pc files and the headers are together) https://packages.debian.org/source/trixie/vulkan-loader

What would be a good strategy to handle this split downstream?

• Make loader depend on headers?
• Build them together as if they were the same project? (In Arch this would mean one package, while in Debian this means runtime and dev files are split, according to the distro rules)
• Make downstream projects not assume the the .pc file is relevant for the headers and do manual header checking, in the same prefix I'd guess?

Thanks!

[charles-lunarg]

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.

[charles-lunarg]

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).

[benjamin-otte]

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.

[charles-lunarg]

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.

[benjamin-otte]

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.