[cmake] explicitly "require" certain VK::Headers version

[crueter]

A common problem we face when vendoring OR system-including Vulkan::Headers and Vulkan::UtilityLibraries is version mismatching, which causes cryptic compile errors that are otherwise incomprehensible to the average user. A specific CMake flag, compile definition, or preprocessing check to "lock" the VulkanHeaders to a specific version or commit hash and generate a compiler (maybe CMake?) error if the versions don't match would be helpful.

[charles-lunarg]

Whoops, I didn't see this issue until now. Which is fine, because I found a way to easily implement this.
#318

Setting the version inside of the project and using that version in find_package(Vulkan-Headers) makes it impossible for CMake to configure with the wrong (ie, too low) header version.

[crueter]

Does this work for system installations? e.g. if the user installs VUL 1.4.326 and VH 1.4.321 on the system?

Also, we have seen issues with vulkan headers that are too new sometimes.

[charles-lunarg]

What do you mean by system installations?
I am not aware of a mechanism for installed code to check that other installed code is the correct version, except through careful management of the packages before installation. IE package managers handle this responsibility.

I do understand what you mean by adding checks to make sure that the header versions are 'new' enough, but I am not sure that is really the responsibility of the header files themselves.

And there is almost nothing to be done about having too new headers, the Vulkan API is supposed to be backwards compatible. A couple of times they are not, but the break is isolated and for the better of the API (like fixing an egregious mistake in a vendor only extension.

[crueter]

What do you mean by system installations?

cmake --install target specifically. I think this just boils down to also adding the minimum version to the generated config file specifically CMakeLists.txt:88

the Vulkan API is supposed to be backwards compatible

I just now realized I had it backwards. I had Vulkan Utility Libraries 1.4.321 on my system and was using a bundled VH 1.3.274 or so.

[charles-lunarg]

cmake --install target specifically. I think this just boils down to also adding the minimum version to the generated config file specifically CMakeLists.txt:88

I certainly could look into adding a check there, I'm not a CMake guru so it will take some time to get it right (not saying its hard, its just an unknown)

I just now realized I had it backwards. I had Vulkan Utility Libraries 1.4.321 on my system and was using a bundled VH 1.3.274 or so.
Well, 1.4.321 > 1.3.274. Vulkan doesn't use semantic versioning, so only the patch version (321 & 274) matters here and so Vulkan-Utility-Libraries definitely needs Vulkan-Headers to have the same patch version (or higher).

Regardless, this brings up the question of whether projects should do their own version checking (putting macro guards in the header files) or should rely on external mechanisms, like package managers, to do the checking for them. I do think adding more logic to the install step, so that it detects that installing it will yield a broken package, is good. Again, not 100% how to do that and can't make any promises.

Since there is more to be done, I will reopen it.

[crueter]

You can just append the version to the find_dependency macro on the line I linked earlier: https://cmake.org/cmake/help/latest/module/CMakeFindDependencyMacro.html

Although I'm sure some package maintainer's gonna be mad, but eh, what can you do.