Closed sarnex closed 1 year ago
FYI: @tgurr @juan-lunarg
FYI: @tgurr @juan-lunarg
I've no experience on how Gentoo handles multilib, but should't you be able to add your cmake-multilib
magic like done for vulkan-loader to vulkan-headers as well to get what you need? On Exherbo for example there's no /usr/include
per se as we have proper cross compilation installing headers on each arch into their respective include directory under prefix e.g. /usr/x86_64-pc-linux-gnu/include
& /usr/i686-pc-linux-gnu/include
and since this path is referenced in the cmake files we can't have just one file in /usr/share for multiple archs, like stated in https://github.com/KhronosGroup/Vulkan-Headers/pull/326.
Side note: In the nv-codec-headers package I mentioned in my initial pull request the Gentoo package also applies some workaround moving the pkg-config files to/usr/share
: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/nv-codec-headers/nv-codec-headers-11.1.5.2.ebuild#n21
@tgurr Thanks for the response.
Sure, from a technical perspective we can do that, but I don't think it's the right solution. We do that for the other vulkan packages because binaries are built, which is obviously arch dependent.
My understanding (and correct me if I'm wrong, this assumption is fundamental to my point) is that there are no arch-specific headers in vulkan-headers. My understanding is everything is arch independent.
If so, we should not install into arch-specific directories. If we do that, the same exact files are installed twice and take up twice the disk space and it takes twice the computation power to install/copy them for absolutely no benefit to users.
I don't know how Exherbo deals with arch-independant files, but /usr/include is widely used in the Linux ecosystem for arch independent code, so Exherbo must have a general solution for code put in /usr/include. Maybe the files are duplicated for Exherbo, but we shouldn't force that on everyone.
About nv-codec-headers, IMO the ebuild is working around an upstream bug, basically the equivalent of what this bug report is about.
My understanding (and correct me if I'm wrong, this assumption is fundamental to my point) is that there are no arch-specific headers in vulkan-headers. My understanding is everything is arch independent.
That is correct.
If so, we should not install into arch-specific directories. If we do that, the same exact files are installed twice and take up twice the disk space and it takes twice the computation power to install/copy them for absolutely no benefit to users.
Correct. CMake header only libraries that are arch-independent should only have to be installed once.
Thanks, that PR will fix this issue for us.
PR #331 also fixed cross-compilation on Ubuntu distributions as well
Vulkan-Headers is also now consistent with spirv-headers: https://github.com/KhronosGroup/SPIRV-Headers/commit/eae955f0525724526fa602fd126623b9d84599fa
After commit https://github.com/KhronosGroup/Vulkan-Headers/commit/b092b2fccc812453c1d0ec0a829eb8f34f174803, cross compilation is broken.
We need to revert https://github.com/KhronosGroup/Vulkan-Headers/commit/b092b2fccc812453c1d0ec0a829eb8f34f174803 in Gentoo to fix multi-ABI vulkan-loader build
If you compile vulkan-loader in -m32, it looks can't find the vulkan-headers cmake files because they are only installed into the default ABI directory (usually x86_64)
It sounds like the real fix is to also install the headers mentioned in https://github.com/KhronosGroup/Vulkan-Headers/pull/326 to an arch-independent directory like /usr/include, since everything in this repo appears to be arch-independent