+3
-2
pkgs/development/cuda-modules/fixups/default.nix
+3
-2
pkgs/development/cuda-modules/fixups/default.nix
+2
-2
pkgs/development/cuda-modules/generic-builders/manifest.nix
+2
-2
pkgs/development/cuda-modules/generic-builders/manifest.nix
······
+2
pkgs/top-level/all-packages.nix
+2
pkgs/top-level/all-packages.nix
···
+5
-13
pkgs/top-level/cuda-packages.nix
+5
-13
pkgs/top-level/cuda-packages.nix
······# Since Jetson capabilities are never built by default, we can check if any of them were requested# through final.config.cudaCapabilities and use that to determine if we should change some manifest versions.···-# It is important that cudaLib (and fixups, which will be addressed later) are not part of the package set+# It is important that cudaLib and cudaFixups are not part of the package set fixed-point. As described by# > The layering should be: configuration -> (identifies/is part of) cudaPackages -> (is built using) cudaLib.# That is to say that cudaLib should only know about package sets and configurations, because it implements# functionality for interpreting configurations, resolving them against data, and constructing package sets.+# This decision is driven both by a separation of concerns and by "NAMESET STRICTNESS" (see above).