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: Will have to filter that somehow How to handle APIs that can only have a single exclusive driver? Only have a option on the API, rather than ? Have but only install the default driver?
I think NixGL doesn't care about , it probably just exports an ?
The original protest against renaming the path: I feel more strongly about the NixOS options being intuitive than the implementation consistent.
I think was more concerned with it being placed under rather than some other directory in because is very much NixOS-specific while the current is not.
I believe I got all of the packages. Once merged, I should be able to deprecate
This thread is over my head, but I would like to check it , , and need the same? All three have GPU or CUDA support options.
This is more about deprecating usage of the term , as it's a bit of a misnomer. I don't see usage of the legacy OpenGL helpers in those packages.
Talked to , we concluded that we can close this ticket and have a more "NixOS options" specific ticket to represent that work.
Going to do one last pass on documentation to ensure all references have been updated. I'll close this ticket after that sweep
I wonder if needs an update. I'm not offering a PR because I'm out of context. Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating].
Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating]. It should come from the toplevel scope now, so it should never need to default to pulling them out of cudaPackages. I can update the nix expression though.