Feat/cuda stub setup hook

[SomeoneSerge]

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[SomeoneSerge]

RE: NixOS#459416 (comment)

[SomeoneSerge]

Uh a more reasonable diffview via https://github.com/NixOS/nixpkgs/compare/master...SomeoneSerge:nixpkgs:feat/cuda-stub-setup-hook?expand=1

[ConnorBaker]

Doing the pre-increment is how we avoid (( 0 )), so no need for || true.

[SomeoneSerge]

Yeah I much prefer explicit || true without the 4LOC comment

[ConnorBaker]

|| true is redundant when using a pre-increment on a variable with a lower bound of zero. I'll shrink the comment.

[ConnorBaker]

Stubs should not exist at the top-level inside lib; I made symlinks previously so autoPatchelfHook could find them since it does not recurse into lib, but that was a bad approach.

[SomeoneSerge]

I used to keep stubs in a separate output at precisely this level, and on a separate notice I was about to ask why you merged cudart into a single output.

[ConnorBaker]

Build scripts and projects assume the directory layout matches what we've got in the redistributables and patching them to respect multiple outputs is too big a headache. I noticed a number of failures building with CUDA 13 because directory traversal through relative paths was assumed to work but cuda_cudart was split into multiple outputs. It was stupid hard for me to get the CUDA 13 PR merged and I couldn't care about rooting out and fixing all those breakages so I just consolidated -- same thing for cuda_nvcc.

[SomeoneSerge]

patching them to respect multiple outputs is too big a headach

True, that's why we had the extra output with symlinks. One argument I have for the extra output is that we've been lately trying to guarantee that .sos can be found at predictable locations ${out}/lib/${soname}.so, so ${lib}/lib/stubs/libcuda.so -> ${stubs}/lib/libcuda.so... well ok nits

-- same thing for cuda_nvcc.

Yeah this one we never really managed to split properly, the cyclical references...

[ConnorBaker]

It's not enough to just record add the dependency to propagated-native-build-inputs -- that only works if we use stubs exclusively from depsHostHost or later (like buildInputs): https://github.com/ConnorBaker/nix-propagation-behavior/blob/1afbd58f2af1468d4564722b7180cc4d89967ef3/README.md?plain=1#L13-L18

[SomeoneSerge]

Ah, I had momentary doubts whether propagatedBuildInputs was treated differently from propagatedNativeBuildInputs except for offsets. It must be the (( -1 <= hostOffsetNext && hostOffsetNext <= 1 )) || continue block. So should just use propagatedBuildInputs instead

[ConnorBaker]

propagated-build-inputs would mean that we'd have offsets (-1, 0) if the stubs are in nativeBuildInputs and (0, 1) if the stubs are in buildInputs. I think we want (-1, 0) at most.

[SomeoneSerge]

propagated-build-inputs would mean that we'd have offsets (-1, 0) if the stubs are in nativeBuildInputs

Yes, precisely, so it's within bounds of findInputs