RE: CUDA Arch List

• Early on, there has been a talk of maybe making a global config.cudaArchList attribute, analogous to config.cudaSupport that all packages would inherit from. This is so we could switch all nixpkgs' cuda architectures at once
• This was before we had cudaPackages_XX package sets and more or less arbitrary
• Now it might make sense to have global default lists per package sets (they support different ranges of architectures), cudaPackages_XX.cudaArchList. They probably could be implemented as just min/max limits instead
• When drafting a PR on this, it would be nice to provide functions to convert back and forth between a "default" list format (e.g. cmake's CUDA_ARCHITECTURES) and whatever other formats we frequently deal with

RE: Building for single target/building for widest compatibility

A thought that's been brought up here before, although now I'm skeptical of it, is that rather than building for all architectures at once we could cache many single-target builds. The idea is that when the end-user has to build something extra that hasn't been cached, they'd spend less compute

A counter-point would be that the user can override arch list just for their extra package instead

In reply to @me:linj.tech
https://github.com/NixOS/nixpkgs/blob/f0daeb19cbf07d62376f755dac23d1d6d37eea93/pkgs/development/compilers/cudatoolkit/auto-add-opengl-runpath-hook.sh#L6

I'm not familiar with this bash syntax 🤣 But, FYI, I had a variation of this code meant to enumerate the outputs list: https://github.com/SomeoneSerge/nixpkgs/blob/c0fc4b2abc6322db67b4ad4aac1ddb8ddcccfc43/pkgs/development/compilers/cudatoolkit/auto-add-opengl-runpath-hook.sh

Shellcheck still won't like for ... in $(...) though

Here's the original:

pkgs/os-specific/darwin/moltenvk/default.nix
156:    for output in "''${!outputs[@]}"; do

In reply to @me:linj.tech
Do you mean for file in $(find $out/{lib,bin} -type f); do?

Offtop, but I imagine this kind of an issue could also arise with a cuda application, and I wonder if you here might be the right people to ask: there's a program that is built with the gcc10StdenvCompat. It links dynamically against gcc10's libstdc++. At runtime the program needs to use opengl libraries (from the same nixpkgs revision), some of which link against gcc11's libstdc++. This results in a failure

I simply don't know what is the right way to deploy something like this (or if there is one) and it's kind of making me sad.

https://github.com/NixOS/nixpkgs/issues/190984