mbeutel/cmakeshift

Common CMake routines and find modules

cmakeshift's Issues

Support Clang for CUDA projects

Add GitHub Pages for this project

Hi,

it would be great to have the documentation (make sphinx) on a gh-pages branch.
That way, GitHub hosts the documentation and it is easily linked to.

I use the same for some of my projects and have a simplistic script to automate updating the branch:

• Update script: https://github.com/mediaelch/mediaelch-doc/blob/master/update_github_pages.sh

Add option to suppress warnings in system headers

Is this suitable for cmakeshift_target_compile_settings()? Probably not because it is accumulative...

Cannot find AddressSanitizer_CUDA_workaround.cpp

cmake_minimum_required(VERSION 3.12)
project(debugcuda LANGUAGES CXX CUDA)

find_package(CMakeshift  REQUIRED)

add_executable(main "main.cu")

include(CMakeshift/TargetCompileSettings)
cmakeshift_target_compile_settings(main
    PRIVATE
        default
		diagnostics
        $<$<CONFIG:Debug>:runtime-checks>)

try to build with cmake -DCMAKE_BUILD_TYPE=Debug ..

results in an error:

CMake Error at CMakeLists.txt:7 (add_executable):
  Cannot find source file:

    /CMakeshift/detail/CMakeshift_AddressSanitizer_CUDA_workaround.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

Support clang-cl on Windows

...and possibly also the GCC-style driver!

AddressSanitizer & CUDA

ASan and CUDA still cause tooling incompatibilities:

• nvprof fails due to wrong preload order if ASan is enabled (check can be suppressed with ASAN_OPTIONS=verify_asan_link_order=0, with unknown consequences for ASan accuracy [I observed some false positives])
• cuda-gdb and other ptrace-based tools don't work with the leak sanitizer in ASan (can be circumvented by disabling the leak checker with ASAN_OPTIONS=detect_leaks=0)

(Question: does the latter issue not appear in CPU-only code?)

This raises the question whether ASan should perhaps not be on by default, either by not including it in runtime-checks, or by not teaching users to use $<$<CONFIG:Debug>runtime-checks> in their settings, and rather set this via cache.

CUDA device invisible in debug build

You have a C++ library which uses CMakeshift to configure the compile settings with:

# compiler settings
include(CMakeshift/TargetCompileSettings)
cmakeshift_target_compile_settings(mycpplib
    PRIVATE
        default
	diagnostics
	$<$<CONFIG:Debug>:runtime-checks>
)

and another CUDA executable which links against that library:

add_executable(cuda_executable ...)
target_link_libraries(cuda_executable
mycpplib::mycpplib
)

If this executable is build with -DCMAKE_BUILD_TYPE=Debug no CUDA device is found any more. This is caused by runtime-checks in the CMakeshift compile settings. If no runtime checks are activated everything works fine.