cudaPackages: mark source-based releases as broken if cudaSupport is false

[ConnorBaker]

For source-available packages like CUDA samples, NCCL, NCCL-Tests, and Saxpy, we should mark them as broken if cudaSupport is false. My reasoning is this: when source-based packages generate code for GPUs, we should make certain cudaSupport is enabled.

However, binary-based packages should not be marked as broken if cudaSupport is false (not explicitly anyway -- it's fine if they're broken due to a dependency on a package marked as broken) because they do not generate (or perhaps even contain!) GPU device code. As an example, cuobjdump doesn't require a GPU to run and should be usable even if cudaSupport is false (assuming allowUnfree is true).

@NixOS/cuda-maintainers @SomeoneSerge @samuela thoughts?

---

Add a :+1: reaction to issues you find important.

[SomeoneSerge]

Why would these packages take a cudaSupport argument if they only exist as cuda variants?

[samuela]

IIRC there are some packages that try using CUDA at runtime and fall back on CPU. Admittedly I don't remember who's doing this (maybe blender or something like that?), or if they're source builds.

But I'm not opposed to marking a source-built package broken if there's no reasonable way the build would succeed without cudaSupport. In that case I guess @SomeoneSerge 's question stands: "why accept a cudaSupport argument if they have no other reasonable configuration?"

[SomeoneSerge]

IIRC there are some packages that try using CUDA at runtime and fall back on CPU. Admittedly I don't remember who's doing this (maybe blender or something like that?), or if they're source builds.

Not in the cudaPackages namespace though?

[samuela]

Oh true! None in the cudaPackages namespace thankfully