Recommended way for using this in a project?

[morsingher]

Hi, thank you for this amazing work. I can build and run the examples successfully and smoothly.

I'm wondering what is the recommended way for using this library in a separate CMake project. Assume to have a folder structure as follows:

src
|_ main.cu
|_ cuda

where cuda is your code and main.cu anything you want (e.g. the vector addition program). I can build this by appending the following two lines to your CMakeLists.txt:

add_executable(test src/main.cu)
target_link_libraries(test runtime-api)

What I would like to do is to get rid of your long CMakeLists.txt and just link the static library libcuda-nvtx-wrappers.a that is generated. Something like this:

cmake_minimum_required(VERSION 3.17)
project(test LANGUAGES CUDA CXX)
add_executable(test src/main.cu)
target_link_libraries(test /path/to/libcuda-nvtx-wrappers.a)

This naive solution results in a "no such file or directory" for "<cuda/runtime_api.hpp>". How would I do that? Would you consider adding a MWE (Minimal Working Example) in the Readme? I think this would help other users as well.

Thank you in advance!

[eyalroz]

I assume you need the NVTX wrappers as well, since - if you do not, then the runtime-API library is just header-only, and you don't need that .a file at all.

But regardless - that's not how you want to use one CMake project in another one. This doesn't carry dependencies; nor does it let you apply library version constraints; nor allow the user to replace the library version they're using (e.g. to use the cuda-api-wrappers version they've installed on their system).

The idiomatic way, given project proj_a exporting target proj_a::tgt and project proj_b is to do the following:

1. Download the sources of proj_a.
2. Configure proj_a with CMake, using some relevant prefix path (it could be /opt/proj_a, or even, if proj_a only provides statically-linked object code, /path/to/proj_b/third-party/proj_a.
3. Install proj_a under its configured prefix path. This is a crucial step and is in fact not trivial to arrange, as CMake installation features are tricky and still evolving. Anyway, part of what gets installed are CMake scripts, under ${CMAKE_INSTALL_PREFIX}/lib/cmake/proj_a/. Access to these is what lets you use the targets exported by proj_a in proj_b
4. In the CMakeLists.txt file of proj_b, you write (using your example):

   cmake_minimum_required(VERSION 3.17)
   project(proj_b)
   find_package(proj_a 1.2.3)
   # ... define some target named b_tgt
   target_link_libraries(b_tgt proj_a::tgt)
   

   and that should be it.
5. Now, if you expect proj_a to be installed in a subfolder of proj_b, then you can add that subfolder to the search paths: find_package(proj_a 1.2.3 PATHS /some/where). Also, as the user building proj_b, if you've installed proj_a someplace other than, say, under /usr or /usr/local, you should set an proj_a_DIR environment variable, which would make CMake search that directory for the lib/cmake/proj_a library and the scripts in there.

[eyalroz]

I trust this answers your question.

[morsingher]

Hi @eyalroz, sorry for the late reply. Your answer was more than exhaustive, thanks :)