This makes things consistent between when glslang is installed and imported versus when it's included as nested CMake project. You can now use glslang::glslang in both cases instead of needing the non-namespaced version sometimes and the namespaced one other times.
Note: Some downstream projects may be using system-installed glslang as glslang instead of glslang::glslang, but this is fragile and isn't actually supposed to work - when passing an un-namespaced library name to target_link_libraries, if it's not an existing CMake target, CMake won't emit an error, and will fall back to just adding an extra linker flag like -lglslang. If you've already got the right library directory enabled (which is likely if you're using the system package), then it'll look like it's working, but you won't get any of the extras like CMake automatically setting up the right transitive include directories.
This makes things consistent between when glslang is installed and imported versus when it's included as nested CMake project. You can now use
glslang::glslangin both cases instead of needing the non-namespaced version sometimes and the namespaced one other times.Resolves one of the problems discussed in https://github.com/KhronosGroup/glslang/issues/3509
Note: Some downstream projects may be using system-installed glslang as
glslanginstead ofglslang::glslang, but this is fragile and isn't actually supposed to work - when passing an un-namespaced library name totarget_link_libraries, if it's not an existing CMake target, CMake won't emit an error, and will fall back to just adding an extra linker flag like-lglslang. If you've already got the right library directory enabled (which is likely if you're using the system package), then it'll look like it's working, but you won't get any of the extras like CMake automatically setting up the right transitive include directories.