Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
vulkan-validation-layers: 18.104.22.168 -> 22.214.171.124 #51672
This requires knock-on upgrades for glslang and spirv-tools.
I have also made the validation layers easier to use:
Previously, one would have to modify LD_LIBRARY_PATH or install the
Motivation for this change
This requires knock-on upgrades for glslang and spirv-tools. I have also made the validation layers easier to use: - library files identified by layer definitions now use absolute paths - the layer definition path is prepended to XDG_DATA_DIRS Previously, one would have to modify LD_LIBRARY_PATH or install the derivation in a known location for vulkan-loader to find relevant files. These changes make using validation layers in a nix-shell work automatically. Use XDG_DATA_DIRS environment variable rather than VK_LAYER_PATH
I'm not sure how to advance this as it was intended primarily as a usability improvement since I had trouble making the existing packaging work. There is a reasonable argument that this constellation of packages -- vulkan-loader, vulkan-headers, glslang, spirv-tools, spirv-headers, and probably others -- should be reconsidered given the way upstream cuts releases. Namely, upstream effectively treats everything as a submodule, but doesn't use the native git mechanisms for doing so.
It might make sense, then, for nixpkgs to move dependencies into the packages that require them (either as
I'm not going to make a sweeping change as I don't know if there is a broader willingness to do so, and everything other than the validation layers was already working fine. But it seems that this PR is stuck on the derivation naming objection until someone does the necessary refactoring.
I'll try to find a home for the usability changes on NUR or somewhere so anyone else wanting to use the validation layers can have an easier time.
I think the right way to go forward in the future is to switch the exposed packages of glslang and spirv-tools to use the release tags they seem to have finally started making (even shaderc has one now!), then use overrides or local definitions as needed in vulkan-* and shaderc. Might be best to pursue that in a separate PR, though.
Vith of these sound like very good ideas, and I strongly encourage both of you to follow up on them. We shouldn’t have packages pinned to a specific git commit in nixpkgs just because that’s what one dependent package wants. For now, I don’t think that updates should be blocked on that, but it really should be fixed sooner rather than later — if other things start to depend on those packages, them being at arbitrary commits could start to cause problems.