Hello Matt, On Sun, Mar 10, 2024 at 11:00 PM <matt...@fennell.dev> wrote:
> Thanks Bret for your work to package this. I've been keeping an eye on > upstream > and this ITP for a while. > I'm glad someone is! I appreciate it. > 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: > Indeed, I created an issue to track this and Robert is aware of the situation. AnyOldName3 and myself are working together with upstream glslang that would make it findable and work correctly via cmake so that cmake itself would not have to carry its own vulkan and glslang files. [1] > I believe this approach would violate Debian Policy on vendored > dependencies, > which are already available in glslang-dev. > Agreed and I've held off pushing this further until I could get vulkanscenegraph package to build against system glslang. It's actually much worse that that, it will try to pull in the glslang code during cmake configuration time, which is not allowed during buildd. > I see a few options: > > 1) We work with upstream to unvendor the dependency > We are already doing this. :) The trickle down should be happening now. [2] > 2) We disable the shader compiler part of vsg > Please no; while this would get the package into Debian faster it would be useless for OpenMW, or specifically the Vulkan work we are doing there which makes use of VSG's glslang. > 3) We patch the build to depend on Debian's glslang package > If we can't wait for 1 to trickle down into Debian's repo; this is a way forward. I have a branch I've been working on that would resolve that. [3] What are your thoughts? Cheers, Bret [1] https://github.com/vsg-dev/VulkanSceneGraph/issues/1035 [2] https://vulkan.lunarg.com/issue/home?limit=10;q=;mine=false;org=false;khronos=false;lunarg=false;indie=false;status=new,open [3] https://github.com/psi29a/VulkanSceneGraph/pull/5
