CoreNEURON uses deprecated FindCUDA

[olupton]

Is your feature request related to a problem? Please describe.
FindCUDA has been deprecated since CMake v3.10, and CUDA has had first-class language support since v3.8.

Describe the solution you'd like
We should avoid deprecated features and follow upstream recommendations, i.e. stop using FindCUDA, cuda_add_library etc.

Additional context
I suspect that the legacy code does not correctly declare all build dependencies, and that it is responsibly for cmake --build re-running the CMake configuration more often than necessary.

[olupton]

See also: https://cliutils.gitlab.io/modern-cmake/chapters/packages/CUDA.html

[alkino]

We have to support both for a long time, minimum version of cmake for CoreNeuron is 3.7.

[pramodk]

@alkino : With 8.0 release done, we can bump the minimum requirement to from 3.7 to something more "reasonable".

[olupton]

In #609 I moved to using CMake's CUDA language support, initially using CMake v3.20. I then added workarounds for older versions back to v3.15.

An attempted GPU build with CMake v3.10 / CUDA 11.0 / NVHPC 21.7 did not go so well. CMake labels the NVHPC C/C++ compilers as PGI 21.7, but it does not know how to detect the language features that they support. And it does not seem to be possible to distinguish programmatically between the two cases:

• C++ feature X is known to be unsupported by PGI/NVHPC version Y
• No test is implemented for C++ feature X for PGI/NVHPC compilers

The result is that the check introduced in #591 fails. If this test is disabled for PGI/NVHPC, we hit a similar issue with the catch2 submodule of NEURON. If we add workarounds for both of these (I just skipped the check for CoreNEURON and manually kludged CMAKE_CXX_COMPILE_FEATURES for catch2, but it's not important) then there is a further issue:

[19/199] Linking CXX executable bin/lfp_test_bin
FAILED: bin/lfp_test_bin
: && /gpfs/bbp.cscs.ch/home/olupton/spack/opt/spack/linux-rhel7-x86_64/gcc-9.3.0/nvhpc-21.7-j4zbmu/Linux_x86_64/21.7/compilers/bin/nvc++  -tp=haswell -acc -gpu=cuda11.0,cc60,cc70 --diag_suppress 161,177,550 -mp   -g  -O2  -cuda external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/lfp.cpp.o external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/cmake_device_link.o  -o bin/lfp_test_bin -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/hpe-mpi-2.22.hmpt-r52ypu/lib  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/cuda-11.0.2-kb4wci/targets/x86_64-linux/lib/stubs  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/cuda-11.0.2-kb4wci/targets/x86_64-linux/lib  -L/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/compilers/2021-01-06/linux-rhel7-x86_64/gcc-4.8.5/gcc-9.3.0-45gzrp/lib -Wl,-rpath,/gpfs/bbp.cscs.ch/home/olupton/nrn/build_ollimod2c/bin/x86_64:/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/externals/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/hpe-mpi-2.22.hmpt-r52ypu/lib:/gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/libraries/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/boost-1.73.0-ell6js/lib -lpthread -lmpi++ -lmpi /gpfs/bbp.cscs.ch/ssd/apps/hpc/jenkins/deploy/libraries/2021-01-06/linux-rhel7-x86_64/gcc-9.3.0/boost-1.73.0-ell6js/lib/libboost_unit_test_framework-mt.so lib/libcoreneuron.a bin/x86_64/libcorenrnmech.a -lpthread -lmpi lib/libcudacoreneuron.a -lrt -lcudart && :
external/coreneuron/tests/unit/lfp/CMakeFiles/lfp_test_bin.dir/cmake_device_link.o: In function `__cudaRegisterLinkedBinary_45___external_coreneuron_tests_unit_lfp_lfp_cpp':
/gpfs/bbp.cscs.ch/ssd/slurmTmpFS/olupton/2468239/tmpxft_000422d1_00000000-3_cmake_device_link.reg.c:2: undefined reference to `__fatbinwrap_45___external_coreneuron_tests_unit_lfp_lfp_cpp'
pgacclnk: child process exit status 1: /usr/bin/ld

which is presumably because of

The CUDA_RESOLVE_DEVICE_SYMBOLS target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries.

from the v3.14 release notes, but the changes of #609 rely on setting this property on executable targets. This looks more awkward to work around.