glslang min_request_version does not accept 15.0.0

[psi29a]

Describe the bug
Looks like cmake is not parsing 15.0.0 correctly and claims that it does not meet the min requirement of 14.

To Reproduce
Steps to reproduce the behavior:

Debian Sid

https://packages.debian.org/source/sid/glslang

cmake .

CMake Warning at CMakeLists.txt:47 (find_package):
  Could not find a configuration file for package "glslang" that is
  compatible with requested version "14".

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0
    /lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0



CMake Warning at CMakeLists.txt:52 (message):
  glslang not found.  ShaderCompile support disabled.

Expected behavior
Should configure and find glslang

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Debian Sid
• Version 1.1.7

Additional context
I'm packaging VSG upstream to Debian

[psi29a]

Change the value to "14.0.0" does not resolve the issue either.

CMake Warning at CMakeLists.txt:47 (find_package):
  Could not find a configuration file for package "glslang" that is
  compatible with requested version "14.0.0".

  The following configuration files were considered but not accepted:

    /usr/lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0
    /lib/x86_64-linux-gnu/cmake/glslang/glslang-config.cmake, version: 15.0.0

[robertosfield]

Could the glslang-config be buggy and not accepting support for older versions? Or is 15 not officially compatible with 14?

I wonder if removing the version check in the find_package line and then checking the version if it's found might work.

[AnyOldName3]

As we discussed last time this came up, glslang's generated CMake config (specifically glslang-config-version.cmake) is set up to deny backwards compatibility if there's a major version change. There are options that let us specify a maximum version, too, but they're ignored if the major version differs for the minimum and maximum we set, so they won't save us here.

I don't think they set things up like that intentionally, it's just how CMake defaults to doing things, and they seem to expect that most projects using glslang use a Windows-style workflow where you clone and build the specific version of all dependencies that you want, instead of the Linux-style workflow, letting the system package manager provide your dependencies and having to deal with whichever versions it decides to give you. If we report it to them, it'll probably sit around unsolved like most of their CMake problems, but they'd probably accept a well-reasoned PR. I think I looked into it and decided it wasn't trivial, so would require at least a little bit of thought, so put it off for another day.

In the meantime, just set GLSLANG_MIN_VERSION to 15 by setting -DGLSLANG_MIN_VERSION=15 on the command line during configure, and everything should be fine.

[psi29a]

Alrighty, we resolved it and package is here: https://mentors.debian.net/package/vulkanscenegraph/
Awaiting lawyer review from FTPMasters and uploading.

Once there, I'll package up the rest: vsgXchange and examples.

Feel free to close this.

[robertosfield]

What was the solution? To use Chris' suggestion?

It'd be good to have a general solution of the box so won't close it for now.

[psi29a]

For the Debian package we just patched the GLSLANG_MIN_VERSION to 15 from 14. It's less work for us to carry this patch and drop when no longer necessary. We want to keep our d/rules clean, so no need to set a define.

https://salsa.debian.org/games-team/vulkanscenegraph/-/blob/master/debian/patches/001-glslang-min-version.patch?ref_type=heads

[timoore]

I just ran into this using VSG from vcpkg. There the workaround is to create an overlay that passes -DGLSLANG_MIN_VERSION=15 to vcpkg_cmake_configure. The proper thing to do is to submit a PR to vcpkg that includes this change. Does anyone claim ownership over the vsg port in vcpkg? I see that @gwaldron submittted that last PR there; Glenn, do you want to make this change, or should I go ahead and do it?

[gwaldron]

@timoore I will look into this today - thanks.

[update]
@timoore I grabbed the latest vcpkg and rebuilt vsg, vsgXchange, and vsgQt via Rocky. glslang version = 15.0.0.
It built OK, but I got this runtime error:

[vsg critical] VulkanSceneGraph not compiled with GLSLang, unable to compile shaders.

Adding -DGLSLANG_MIN_VERSION=15 to the portfile fixes the problem, confirmed.

So I will submit that PR to vcpkg to support 1.1.7, and @robertosfield can make the call whether to burn this into VSG proper for the next tagged release.
microsoft/vcpkg#42294

Hope that works :)

[robertosfield]

I have done some experiments on my Kubuntu 24.04 system that has either glslang-dev package installed that has glslang 14.x or glslang built from source that is 15.x.

Without any changes I saw the same cmake error as others have reported. To workaround this issue I have refactor the glslang find code so that it first tries 15, and if that fails fallbacks to trying 14. The change is now checked into VSG master: e07a9a7

I will be tagging a VSG dev release later today/tomorrow that will include this. Would appreciate others have a look over it and ideally test it as well. Thanks.

[AnyOldName3]

We're probably going to have the same issue with glslang 16 when it appears (unless we convince the upstream maintainers to customise their glslang-config-version.cmake so it accepts a version range that spans multiple major versions before it's branched), so it might be sensible to use a loop instead of having two explicit find_package calls.

[gwaldron]

FWIW, the vcpkg team would only accept a patch that passed in -DGLSLANG_MIN_VERSION= which disables the explicit check and works with both 14 and 15 (and presumably 15+ in the future, which drove their reasoning).

[AnyOldName3]

The original problem was that we knew 13.x and older definitely didn't work properly on Windows as glslang's CMake was a mess. vcpkg's glslang port had workarounds for many of the problems, so older versions from there were mostly fine anyway, so the minimum version check is less important there.

The original intention was that the check would permit 14+, and it was only when 15 was released that we realised it meant $[14,15)$ as major versions had to match, even when the upper bound is explicit.

[robertosfield]

I have been wondering about simply dropping the version check on the find_package and trying to come up with an alternative version check in the CMake.

We used to have a bit of convoluted systems for detecting glslang version but that got removed when I moved glslang to be internal.

[AnyOldName3]

The main reason I can think of not to do that is that having it in the find_package call means that it'll skip older versions that it finds first. It's pretty common to have multiple glslang builds installed side-by-side as the Vulkan SDK provides one, and it'd be a pain if someone's Vulkan SDK wasn't up to date, so provided an older glslang build, and the VSG insisted on trying to use it even though it was too old and a newer one was also installed. On the other hand, this problem can be avoided by changing the order things are listed in CMAKE_PREFIX_PATH etc. so the desired build is found first.