Generate pkg-config file during install builds

[jasonliu--]

This commit causes CMake to generate a pkg-config file when ENABLE_GLSLANG_INSTALL is enabled. This allows software projects that use pkg-config (and not CMake) to locate external dependencies (e.g., Godot 4.x), to find and properly link to a pre-built glslang package.

Closes #1715.

[arcady-lunarg]

Unfortunately the pkg-config file that this produces doesn't actually work, when I try to build with pkg-config I get undefined errors because libglslang.a isn't actually self-contained and you generally will need to link against at least libSPIRV.a as well. Same goes for shared library builds I think. We're working on unifying the two into one single library file though, please see #3320.

[jasonliu--]

Hi @arcady-lunarg, so are you saying that the pkg-config file doesn't work in general as a concept, or are you saying that it's missing some pieces, i.e. also needing to link against libSPIRV.{a,dylib} as well? Because if it's the latter, could you let me know what are the minimum libraries that are needed? Just libglslang and libSPIRV? What about the other libs, libHLSL and libSPVRemapper? And how about static-only libraries, such as libGenericCodeGen.a, libMachineIndependent.a, libOGLCompiler.a, libOSDependent.a, libglslang-default-resource-limits.a; are those all required to link statically against glslang? I could easily add them to the Libs: line in the pkg-config file, that's no problem.

[arcady-lunarg]

The pkg-config file is fine as a concept, but your implementation of it is broken. I suggest waiting a little while for me to finish the work of rearranging the libraries a bit and then your pkg-config file will actually be correct.

[jasonliu--]

Sure, waiting is not a problem right now.

Most of the downstream software that we currently have packaged in MacPorts are building and running fine linking against glslang because they all use CMake to build. Godot is the only downstream project that must use pkg-config because they use scons as their build system. In addition, the devs are still in the process of integrating glslang, so they are currently cherry-picking certain pieces from your source code, and compiling them during the build as internal dependencies.

My wanting to add the pkg-config file was mostly just in preparation for when the Godot devs fully integrate all of the features of glslang that they want to use into their codebase, at which point in time, assuming that they haven't added too many custom patches of their own which they never contribute upstream, it will be possible to simply link Godot 4.x to a pre-built glslang dylib by using the pkg-config file. Hopefully by then you will have already been able to rearrange the glslang libraries to have an API/ABI that is completely available using just libglslang as a single entry point. Until then, I think it's perfectly reasonable to hold off on merging this PR.

If after you have rearranged the libraries, you think that I need to change the pkg-config file in some way (maybe there are some static-only libraries that have to remain separate for some reason), please let me know, I can add them to a Libs.private: line in the pkg-config file so that the additional static libs only get linked when a downstream project uses the pkg-config --static option.

[juan-lunarg]

• This doesn't properly handle BUILD_SHARED_LIBS.

Libs.private is only needed when BUILD_SHARED_LIBS is OFF.

• Doesn't handle absolute installation locations which can be provided to CMake:

See: KhronosGroup/SPIRV-Headers#282

• Testing?

Both vulkan-loader and spirv-headers currently test the generated .pc file to some extent. If the testing doesn't happen here it should happen during SDK testing since adding this will mean verifying another deliverable.

[jasonliu--]

@juan-lunarg , do you believe that the same technique that is used in the issue you referenced would also work here for glslang?

Both vulkan-loader and spirv-headers currently test the generated .pc file to some extent. If the testing doesn't happen here it should happen during SDK testing since adding this will mean verifying another deliverable.

I'm willing to add similar tests to this PR, I wasn't aware that other projects were doing these tests.

[juan-lunarg]

@juan-lunarg , do you believe that the same technique that is used in the issue you referenced would also work here for glslang?

Yes but keep in mind that is a header only library. You can look at the loader code as well for reference.

NOTE: The loader's package config is simpler since the loader can only be installed as a SHARED library so there isn't a perfect example for you to look at.

I'm willing to add similar tests to this PR, I wasn't aware that other projects were doing these tests.

👍🏾

[juan-lunarg]

@juan-lunarg , do you believe that the same technique that is used in the issue you referenced would also work here for glslang?

This repo actually summarizes the issue nicely
https://github.com/jtojnar/cmake-snips#assuming-cmake_install_dir-is-relative-path