Alpaka: CMake CUDA: 'target_compile_options' has no effect

[tdd11235813]

TARGET_COMPILE_OPTIONS(                     
    ${_TARGET_NAME}                         
    PRIVATE ${_COMPILE_DEFINITIONS_PRIVATE} 
    PRIVATE ${ALPAKA_DEV_COMPILE_OPTIONS})  

Such cmake usage requirements of a target as shown above have no effect on CUDA targets. It seems these only accept add_definitions, add_compile_options, .. :sigh:
It seems it only affects target_compile_options which are not forwarded to nvcc and can be remedied by target_compile_definitions instead.

Flags passed into add_definitions with -D or /D are passed along to nvcc.

cmake 3.10 doc
Does not affect all examples or test cases, as not all of them use the CUDA backend.

But in general, it seems to be better to not use cuda_add_*. These are less transparent, magic stuff happens backstage and less controllable:

Unfortunately, these commands [cuda_add_*] are unable to participate in usage requirements, and therefore would fail to use propagated compiler flags or definitions.

modern cmake + CUDA | cmake usage requirements

So these CUDA parts in our cmake files addExecutable.cmake should be refactored to use add_executable, ... directly.
In this step involving integration of CUDA's separable compilation and linking feature should be done as well, to enable more complex programs/libraries built with alpaka.

Edit: link to separate compilation blog post added.

[BenjaminW3]

At least since CMake 3.7 the target_compile_options and target_include_directories should be supported. We explicitly removed a lot of such special casing with this commit. I am really sure that this works because I have had a look over the code changes in CMake at that time.

We should not be using any cuda_add_* calls anywhere within our code. Everything should be using ALPAKA_ADD_EXECUTABLE which maps to either add_executable or cuda_add_executable.

I am open for using more modern approaches and any help is appreciated. We can not yet use the CMake built in CUDA language support because it does not support clang as a CUDA compiler.

[tdd11235813]

thanks for clarifying on this. Yes, I mean the cuda_add_executable behind the alpaka_add_executable.
I tested this issue with cmake 3.10.1 with CUDA enabled vectorAdd example. The target_compile_options are not forwarded to the nvcc. target_compile_definitions indeed does, tested on test/integ/cudaOnly.
Here, the target_compile_options also has no effect, but is remedied by a subsequent TARGET_COMPILE_DEFINITIONS.

So first thing could be to replace target_compile_options with target_compile_definitions where appropriate?

[ax3l]

This could be a similar issue as with the "forgotten" SYSTEM attribute in includes.
Ideally, we should use the new language feature CUDACXX for CMake nowadays but that one does not yet support clang -x as device compiler. That's why we take the cuda_add_executable wrappers still...

If someone want's to volunteer to implement clang as device CUDA compiler inside CMake, I have detailed instructions from @robertmaynard how this can be added.

[ax3l]

CMake 3.18.0 supports clang (-x cuda) as CUDA compiler! And one can propagate device linker flags with a DEVICE_LINK generator expression. Alpaka can transition to first-class CUDA support now :tada:

cc @j-stephan in case you haven't seen this already:
https://blog.kitware.com/cmake-3-18-0-available-for-download/

[BenjaminW3]

I will start trying this out but it may take some time.
First step is adding CMake 3.18 into CI with our current FindCUDA based builds.