Compiling cuStateVec with CMake

[TysonRayJones]

Hi there,

I am incorporating cuStateVec into a C++ project as a dynamic library using CMake, and although it works, I'm apprehensive I'm not using best practice. For context, I've installed cuquantum-cuda-11 via apt-get on Ubuntu 20.04 as per these instructions, which has created (among many others) relevant files:

• /usr/include/custatevec.h, which #include's existing files in /usr/local/cuda/include/ (such as library_types.h)
• /usr/lib/x86_64-linux-gnu/libcuquantum/11/libcustatevec.so (and .a, etc)

I have an existing CMake project which uses CUDA (without cuStateVec). Since it intends to support (very) older CMake versions, the root CMakeLists.txt does not declare CUDA as a language, i.e. via project(myProject LANGUAGES CUDA), but instead does an old fashioned:

find_package(CUDA REQUIRED)
cuda_add_library(myProject mySourceFiles)
target_link_libraries(QuEST ${CUDA_LIBRARIES})

Already inadvisable of course; please forgive me, I'm stuck with it at the moment!

I now wish to adapt this to include cuStateVec. I expected it to be as simple as replacing the final line above with:

find_library(CUQUANTUM_LIBRARIES custatevec)
target_link_libraries(myProject ${CUDA_LIBRARIES} ${CUQUANTUM_LIBRARIES})

Alas, compiling yields the below error

/usr/include/custatevec.h:134:10: fatal error: library_types.h: No such file or directory
  134 | #include <library_types.h>

indicating that CMake has not included directory /usr/local/cuda/include/.
I can hackily remedy this by adding:

target_include_directories(myProject PUBLIC "/usr/local/cuda/include")

and everything compiles fine, but I'm doubtful this is really addressing the issue.

So; is there an example of compiling cuStateVec with CMake, or additional CMakeLists.txt files I've overlooked?
It's possible the issue is really with my understanding of CMake, and irrelevant to cuStateVec's build, but I'm surprised I didn't have to point other CUDA libraries to the headers in /usr/local/cuda/include.

[mtjrider]

Hi @TysonRayJones thanks for posting this question.
We appreciate that projects have various legacy support requirements and appreciate the situation.

If any of my explanations below are not helpful, please let us know/clarify. Apologies for my long answer.

Without seeing exactly what is being compiled or how, it's difficult to comment on best practices. Can we migrate the best-practices question to a discussion, and can you provide more detail, there? One comment on this without knowing anything specific about your use-case, I'd recommend isolating and compiling artifacts that specifically use CUDA separately and linking them to your target executable/library at the end.

Regarding your other question about include directories: we intend cuQuantum be used like any other CUDA math library, and dependent projects of that library be compiled with Nvidia's toolchain (e.g.) nvcc. See our example makefile.

nvcc will automatically inject CUDA headers, flags, definitions, etc., where needed. You can see what's being injected by increasing verbosity or by performing a dry-run. Here's some documentation on nvcc compilation phases.

If using nvcc to compile certain components is not an option, you can usually get away with adding the headers/flags manually, but I wouldn't generally recommend it. Here's a chart discussing host-compiler support.

[mtjrider]

@TysonRayJones let us know if this is still an issue.

[TysonRayJones]

Hi @mtjrider ,

Sure, feel free to migrate to a discussion if preferred!
I'm afraid though I haven't yet solved the issue, nor understand what would distinguish custatevec from other CUDA libraries to break this cmake build. I'll report my progress, though won't have a chance to try again for a short while. Happy to migrate this in the meantime.