BUG: Resolve CUDA warnings on Linux

[tbirdso]

Resolve CUDA warnings when building with Ninja on Linux. Verified CUDA build succeeds on Linux platform with these changes.

[Leengit]

If it works then this all seems reasonable to me. I would use more indentation so that it is clear when one is in a "then" or else clause, using multiple indentations for nested clauses.

[tbirdso]

Good suggestion, I will fix styling before merge

[Leengit]

Probably an issue with my local configuration, but just in case it is not ... when I set VKFFT_BACKEND to 1 and I use gcc then I get "cuda.h not found"; and if I use nvcc then I get

CMake Error at /usr/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)

[tbirdso]

Thanks @Leengit , I have not been able to reproduce directly on my local Linux machine but I do see the same issue with gcc when I try to build Python CUDA wheels, which is the next step after this.

How do you set whether to use gcc or nvcc in CMake?

In my experimental fork of VkFFT I am having some success in compiling when I explicitly include CUDA headers, but then the linking step fails to find CUDA with -lcuda.

[Leengit]

How do you set whether to use gcc or nvcc in CMake?

I use -DCMAKE_CXX_COMPILER=nvcc -DCMAKE_C_COMPILER=nvcc as command-line parameters to a shell-invoked cmake command.

If it is the use of nvcc that is finding the headers but not the libraries ... I don't know. My first guess is that the appropriate -L parameters that cmake should be setting aren't getting set for that action, and we have to add or adjust some cmake variables.

If it is with use of gcc that is failing then I don't know how we are even finding the headers ... my very limited understanding is that maybe the regular headers are available only for nvcc and we have to #include different file names to get gcc to get anywhere. I could easily be completely wrong about this.

[tbirdso]

I use -DCMAKE_CXX_COMPILER=nvcc -DCMAKE_C_COMPILER=nvcc as command-line parameters to a shell-invoked cmake command.

Excellent, that's probably what I am missing. I will give it a shot. Thanks.

If it is with use of gcc that is failing then I don't know how we are even finding the headers ... my very limited understanding is that maybe the regular headers are available only for nvcc and we have to #include different file names to get gcc to get anywhere. I could easily be completely wrong about this.

Yes, exactly. In my VkFFT fork linked above I have explicitly added a couple of target_include_directories calls to reference the cuda/include directory containing cuda.h and other headers for gcc to succeed. Unfortunately this doesn't address the linking problem.

[tbirdso]

Hm, no luck with explicitly setting the compiler to nvcc:

/opt/rh/devtoolset-10/root/usr/libexec/gcc/x86_64-redhat-linux/10/ld: cannot find -lcuda
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

EDIT: Note that setting the compiler to nvcc does successfully remove the requirement to explicitly include CUDA headers as for gcc. It looks like Threads is found on my system and when building Linux wheels in the container.

[Leengit]

If you are finding cuda and thread headers then you are having better luck than I! Maybe the CMAKE file needs to be told where to find (or install?) the CUDA libraries; perhaps something vaguely similar to what is done for OpenCL in the top-level CMakeLists.txt file.

Alternatively, the cmake variables are already properly set up and the issue is that the libraries were installed in one GitHub environment but are trying to be accessed in another environment ... though maybe that is unlikely given that we are already finding the headers.

[tbirdso]

As we look closer at adding ITKVkFFTBackend as an ITK remote module in InsightSoftwareConsortium/ITK#3363 I would like to go ahead and merge these changes with the reasoning that some success with building on Linux is better than no success. I will add an issue to track remaining issues regarding 1) finding the Threads library and 2) building module wheels to link against + package with CUDA libraries.