* Package name : VulkanSceneGraph Version : 0.1.10 Upstream Author : Robert Osfield <robert@openscenegraph.com> * URL : https://github.com/vsg-dev/VulkanSceneGraph * License : MIT/X Programming Lang: C++ Description : VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library built upon Vulkan graphics/compute API. The project aims to bring the performance of Vulkan to the wider developer community by providing a modern, high quality software library that is easy to use and focused on making the development of high performance graphics and compute applications a productive and fun experience. Sharing the same lead author as the OpenSceneGraph, all the lessons about software quality, performance and the needs of application developers are applied to VulkanSceneGraph to provide a distillation of what a next gen scene graph needs to be. Extra Info: - VSG will be used by OpenMW as it is a replacement for the current OSG library. - osgEarth will probably transition to vsgEarth as well. - Co-maintainers from OSG welcome. - I would maintain it and hopefully members of the games-team as well. - Sponsors always welcome.
Note that package names cannot have upper case letters. See the Debian Policy, section 5.6.1: https://www.debian.org/doc/debian-policy/ch-controlfields.html#source Berto
Thanks Berto, I have a basic build up and I'm working through lintian issues now. Any help or advice you can give would be greatly appreciated. :) https://salsa.debian.org/games-team/vulkanscenegraph Cheers, Bret
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: 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
Hello Matt, I'm glad someone is! I appreciate it. 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] 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. We are already doing this. :) The trickle down should be happening now. [2] 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. 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
bret curtis <psi29a@gmail.com> wrote: Apologies, I somehow missed your Github issue. Looks like you're about 10 steps ahead of where I was when I wrote the email! :) Agreed - 1 makes most sense to me as well. I have a few machines with different configurations, so feel free to mail me if it would help for me to test against your branch (or anything else for that matter). Thanks, Matthew
Hello, I recently discovered that you share a surname with a late client of ours who passed away without a will. This opens a significant opportunity, as a substantial amount has been left behind. Could you please respond at your earliest convenience? Discussing this matter could be highly advantageous for you. All information will be handled with the utmost confidentiality and professionalism. Best regards, Ms.Nicola V. Speak nikkyvspeak@gmail.com
Hello everyone! way [3] With release 1.1.7 we now can use the system gslang, I've added a patch to allow it to work with version 15 currently in Sid. As mentioned here: https://github.com/vsg-dev/VulkanSceneGraph/issues/1326 CMake defaults to doing things, and they seem to expect that most projects using glslang use a Windows-style workflow where you clone and build the specific version of all dependencies that you want, instead of the Linux-style workflow, letting the system package manager provide your dependencies and having to deal with whichever versions it decides to give you. If we report it to them, it'll probably sit around unsolved like most of their CMake problems, but they'd probably accept a well-reasoned PR. I think I looked into it and decided it wasn't trivial, so would require at least a little bit of thought, so put it off for another day. Are we good to go? Anything else? :) Cheers, Bret