Code change:
| Find libraries | `configurePhase` | Missing dependency on a `dev` output | Add the missing dependency | The `dev` output typically contain CMake configuration files | | Find libraries | `buildPhase` or `patchelf` | Missing dependency on a `lib` or `static` output | Add the missing dependency | The `lib` or `static` output typically contain the libraries | <del> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`cudaPackages.autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=cudaPackages.autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </del> <ins> In the scenario you are unable to run the resulting binary: this is arguably the most complicated as it could be any combination of the previous reasons. This type of failure typically occurs when a library attempts to load or open a library it depends on that it does not declare in its `DT_NEEDED` section. As a first step, ensure that dependencies are patched with [`autoAddDriverRunpath`](https://search.nixos.org/packages?channel=unstable&type=packages&query=autoAddDriverRunpath). Failing that, try running the application with [`nixGL`](https://github.com/guibou/nixGL) or a similar wrapper tool. If that works, it likely means that the application is attempting to load a library that is not in the `RPATH` or `RUNPATH` of the binary. </ins>

Related discussion:
text: Global path name and other changes are almost entirely tangential and could happen independantly but I'd appreciate if they came after the NixOS options changes such that we can let the knowledge we gained from the NixOS options influence their design. Anyhow, that's my current draft. Let me know what you think.
My naive assumption was that we'd have a new path but: That was my initial take as well, but there's community projects like nixGL and others who likely have hard coded the path. And there's a potential that we could never fully remove it without breaking someone
Forgive my ignorance, but wouldn't it be ok to make those kinda breaking changes by deprecating in one release and then removing one or two releases later? Surely nixos isn't promising to never change paths because someone might be using the old location? EDIT:I don't mean to imply we shouldn't consider non-breaking options where possible
nixGL only sets the LDLIBRARYPATH? Although in all probability we must break someone's workflow... Fun fact: cudaPackages don't ship the driver (except for for jetsons). All the relevant stuff comes with nvidia_x11 or with the datacenter driver. Interesting. Would we somehow have to filter the glvnd/opencl loader/vulkan loader configs that come with the drivers to enforce that the declarative configuration be implemented?
nixGL appears to be actively maintained. I don't think we need to worry about breaking it as they can simply adapt. Also, we could simply keep providing the old path in both NixOS and binaries with a preference for the new path and that should work out fine. Oh, okay. I'll leave it to you CUDA people to figure that out. I will only be lifting drivers to this interface on a best-effort basis and the rest will keep using their legacy interface with a minor implementation change. Though if you forsee possible issues you could have mapping your driver to this interface, let me know so that we can design the interface better from the start. That or simply write our own. Though I'll only be adding the option where it is feasible; currently, I only know that Vulkan has sane mechanisms for this. Some issues I still need to think about:How to handle drivers that only support 64 bit?