Thanks Bret for your work to package this. I've been keeping an eye on upstream and this ITP for a while.
One thing I noticed is that upstream integrated their own fork [1] of glslang directly into the build [2] as of 1.0.3 [3]. Their reasoning was that: > Relying upon glslang has turned out to be far more painful that it should be, > with the API evolving over the years, different packaging of glslang being > done in various ways on various platforms has meant that it's been a wake a > mole task trying to keep the VSG working on all the various build and runtime > combinations involving glslang and SPIRV-Tools. I believe this approach would violate Debian Policy on vendored dependencies, which are already available in glslang-dev. I see a few options: 1) We work with upstream to unvendor the dependency 2) We disable the shader compiler part of vsg 3) We patch the build to depend on Debian's glslang package 1) seems unlikely without a lot of work to help fix the original issues encountered by upstream. This was a deliberate choice on their side, so it would require some discussion to see if they'd be happy to try. 2) has a build flag for this, but it disables a significant portion of the library. 3) seems doable - I got it working without build or runtime issues locally, but I'm not sure if this would work in all cases, or if upstream would be happy for us to do this without further discussion. Do you have any thoughts on what is the best approach? IANADD, or involved with vsg; I'm just a user, so I may have missed something obvious. [1] https://github.com/vsg-dev/glslang [2] https://github.com/vsg-dev/VulkanSceneGraph/discussions/728 [3] https://github.com/vsg-dev/VulkanSceneGraph/releases/tag/VulkanSceneGraph-1.0.3
