Glslang项目v14版本头文件安装问题解析

glslang作为Khronos Group维护的着色器语言编译工具链，在v14版本中引入了一个重要的变更：默认不再安装所有头文件。这一变更虽然旨在精简安装内容，但在实际使用中却引发了一些兼容性问题。

问题背景

在glslang的构建系统中，CMakeLists.txt文件控制着项目的编译和安装过程。v14版本中，项目维护者有意减少了默认安装的头文件数量，仅保留了Public/ResourceLimits.h、Public/resource_limits_c.h和MachineIndependent/Versions.h等少数几个头文件。

这一变更导致了依赖glslang的项目（如Cemu模拟器）在构建时出现头文件缺失的问题。虽然维护者的初衷是好的——避免安装不必要的头文件，但这一变更过于激进，影响了现有项目的正常构建。

技术分析

glslang的头文件可以分为几类：

1. 公共API头文件（如ShaderLang.h）
2. C语言接口头文件
3. 内部实现头文件
4. 资源限制相关头文件

v14版本之前的安装策略较为宽松，几乎安装了所有头文件。而v14版本则严格限制了安装范围，只保留了最核心的几个头文件。这种变化反映了项目维护者对API边界更加明确的定义意图。

解决方案探讨

针对这一问题，社区提出了几种解决方案：

1. 修改CMakeLists.txt：通过恢复使用${GLSLANG_HEADERS}变量来安装更多头文件，这是最直接的解决方案，但可能违背项目维护者精简安装的初衷。

2. 更新依赖项目：如Cemu项目后来所做的，调整代码使其仅依赖glslang公开的API头文件。这是更符合长期维护的解决方案。

3. 折中方案：在CMakeLists.txt中精心选择需要安装的头文件子集，既满足大多数项目的需求，又不过度安装。

最佳实践建议

对于使用glslang的开发者，建议：

1. 优先使用glslang提供的公共API头文件，这些头文件具有更好的稳定性保证。

2. 如果确实需要使用内部头文件，应考虑与项目维护者沟通，评估这些头文件是否应该被纳入公共API。

3. 在项目构建系统中明确声明对特定glslang头文件的依赖，避免隐式依赖。

4. 关注glslang项目的版本变更说明，特别是关于API和头文件安装的变更。

glslang作为重要的着色器工具链，其API稳定性对生态系统至关重要。这次事件也提醒我们，在开源项目中，API边界的管理和变更需要谨慎处理，平衡精简性和兼容性的需求。