Because cuda compilers are matrix-aligned with other compilers (c, fortran, etc.), skipping all but an old cuda compiler version means pinning all compilers to old versions. As far as I know, this is only a problem for gfortran, where gfortran 7 emits a dependency on libgfortran 4, while gfortran 10 emits a dependency on libgfortran 5, making their build products mutually exclusive at install time (i.e. #94 means openmpi 4.1.3 cannot be installed along with any other package compiled with the current default fortran on conda-forge).
specify cuda_compiler_version explicitly instead of via skips
avoid duplicating version in multiple places, which should prevent future instances of #84
some template shenanigans ('cooda') to avoid pulling in the cuda_compiler zip_keys build matrix. I'm not 100% sure this will work. If not, I think we'll have to subset every entry in the compiler zip_keys lists, which will be tedious to maintain.
Because cuda compilers are matrix-aligned with other compilers (c, fortran, etc.), skipping all but an old cuda compiler version means pinning all compilers to old versions. As far as I know, this is only a problem for gfortran, where gfortran 7 emits a dependency on libgfortran 4, while gfortran 10 emits a dependency on libgfortran 5, making their build products mutually exclusive at install time (i.e. #94 means openmpi 4.1.3 cannot be installed along with any other package compiled with the current default fortran on conda-forge).
closes #94