KhronosGroup / KhronosGroup/glslang
Inconsistency in include paths when glslang is used as a submodule or as an installed cmake library
- Dominant language
- C++
- Stars
- 3.6k
- Forks
- 989
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 31
Description
Here is the part that confuses me a lot https://github.com/KhronosGroup/glslang/blob/main/SPIRV/CMakeLists.txt#L83.
```
target_include_directories(SPIRV PUBLIC
$
$)
```
So let's say there is some library that uses glslang as a submodule. In their CMakeLists.txt, they will add glslang by calling add_subdirectory(...).
So then glslang::SPIRV target in such context will have its` include directory defined as ."./", root of glslang, so that to include GlslangToSpv.h in code it will look like "#include ".
However, if glslang is built and installed and then used as an installed package, it's no longer the case. Now, to include GlslangToSpv.h, the code will have to do this: "#include ".
Why is it designed like that?
Contributor guide
Research direction
Read SPIRV/CMakeLists.txt around line 83, then compare the BUILD_INTERFACE and INSTALL_INTERFACE include paths when glslang is added as a submodule versus consumed as an installed CMake package. Done means explaining the intended include convention and identifying the specific CMake change or documentation needed to remove the inconsistency.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, cpp
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100