user1011113
user1011113

Reputation: 1365

Modern CMake (3.8+) - FindCUDA deprecated, what about non .cu files?

I have a C++/CUDA project based on CMake. Currently I'm using CMake 3.11 and CUDA 9.0 and I'm reading that now CUDA is a first-class language in CMake, so I can simply add .cu files and it will automatically call the NVCC compiler to take care of them. Before this, we had to use find_package(CUDA) and so on, but now this is a deprecated feature.

Now the question: how do we compile normal .cpp files that still make use of the CUDA host libraries? cudaMalloc, cudaFree, etc. My solution so far is to set_source_files_properties(file.cpp PROPERTIES LANGUAGE CUDA) but I don't feel this is the right thing to do. Since this file doesn't contain device code, it should be compiled with the GCC compiler including and linking to the CUDA libraries.

Another issue with this approach is that it propagates very quickly to the rest of the project. Say a header file that defines a struct containing a dims3 variable, then every .cpp file that #includes this header will need to be considered as a CUDA file.

Upvotes: 2

Views: 431

Answers (1)

einpoklum
einpoklum

Reputation: 131646

how do we compile normal .cpp files that still make use of the CUDA host libraries?

With your regular C++ compiler. There is no need to treat them as LANGUAGE CUDA.

I recently made the switch to CMake's native CUDA support in this repository of mine. I now have:

add_executable(device_management 
    EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
add_executable(execution_control 
    EXCLUDE_FROM_ALL examples/by_runtime_api_module/execution_control.cu)

Both of these use the runtime API (actually, they use my C++'ified wrappers, which use the runtime API - but most of the wrappers is header-only), but the second one has a kernel in it, so I made it a .cu and it gets compiled by CUDA. The .cpp builds and runs fine by plain old GCC.

Upvotes: 1

Related Questions