Skip to content
Snippets Groups Projects

cuda: allow C++17 build with CUDA 11+

Closed Seth Johnson requested to merge seth/VecCore:fix-cuda-cxx17 into master

Currently, trying to build with geant4@11 and CUDA fails when CMAKE_CXX_STANDARD is set to 17. (I encountered this building with spack and the cxxstd=17 flag.) This allows C++17 when using CUDA 11 or higher.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Hi @seth, thanks for noticing this. This module, however, is only needed to build VecCore's own tests. You don't need to "build" VecCore for using it with VecGeom/Geant4, you can use any configuration for that. The -DCUDA=ON CMake option is only to enable some tests for a sanity check of CUDA in VecCore itself. I just dropped this check entirely, given that CUDA 11.7 just announced by Nvidia even has some support for C++20. By the way, the official repository for VecCore is the one on GitHub, at https://github.com/root-project/veccore.

  • Aha, thanks for the details: currently the spack recipe sets CUDA=ON for +cuda but I will just remove the variant if it's not needed. I'll also update everything to use github as the source rather than cern gitlab. Should I do the same with vecgeom, or is development for that still proceeding on gitlab?

  • @amadio To follow up on this: if building VecGeom with CUDA enabled, it adds a required "CUDA" component to the VecCore installation, which is only set when CUDA=ON. So the CUDA flag does indeed change the installation and the ability to build downstream codes, so this update is indeed necessary. Thanks for dropping the needless check.

  • VecGeom is still developed on GitLab. The check for CUDA with the component happens in VecCoreConfig.cmake when you call find_package(VecCore REQUIRED CUDA), so when you install VecCore itself, it doesn't need any special configuration (that is, you can drop that from the spack recipe).

    Edited by Guilherme Amadio
  • Ah, thanks for the correction -- I missed that the @CUDA@ wasn't being configured into VecCoreConfig.cmake. Since veccore is an interface library I might as well drop the cxxstd language option as well, right?

  • Yes, that's correct. The headers in the filesystem don't change, the options for VecCore itself are just for enabling features for building/running VecCore's own tests. VecCoreConfig.cmake checks for what backends should be enabled with each call to find_package(VecCore).

  • mentioned in commit sft/spack@1b067ee3

Please register or sign in to reply
Loading