Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase max policy range for CMake to 3.18 #53

Merged
merged 1 commit into from
Oct 14, 2020

Conversation

drbenmorgan
Copy link
Contributor

CMake 3.18 introduced policy CMP0104 on the initialization of the new CMAKE_CUDA_ARCHITECTURES variable and subsequent use of code generation flags. Without this policy being set to NEW, warnings are emitted at CMake generation time about CUDA_ARCHITECTURES not being set for targets.

Bump max CMake policy range to 3.18 to set a default for CMAKE_CUDA_ARCHITECTURES if not supplied by the user.

This can still result in nvlink errors when linking vecgeom_static if that was compiled with architectures incompatible(?) with that for Celeritas. Not sure how to check that yet.

CMake 3.18 introduced policy CMP0104 on the initialization of the
new CMAKE_CUDA_ARCHITECTURES variable and subsequent use of code
generation flags. Without this policy being set to NEW, warnings
are emitted at CMake generation time about CUDA_ARCHITECTURES
not being set for targets.

Bump max CMake policy range to 3.18 to set a default for
CMAKE_CUDA_ARCHITECTURES if not supplied by the user.
@sethrj
Copy link
Member

sethrj commented Oct 14, 2020

Ahhh, so bumping the policy is what automatically sets it. I'd wondered about that. Thanks! It looks like it detects our old K40 as having 3.0 instead of 3.5, but still that's a nice feature to have :)

@sethrj sethrj merged commit 4b0e428 into celeritas-project:master Oct 14, 2020
@drbenmorgan drbenmorgan deleted the update-cmake branch October 14, 2020 11:29
@drbenmorgan
Copy link
Contributor Author

Ahhh, so bumping the policy is what automatically sets it. I'd wondered about that. Thanks! It looks like it detects our old K40 as having 3.0 instead of 3.5, but still that's a nice feature to have :)

Yes, I had this issue on my CUDA 10.2/Quadro P400 setup. That I think led to the VecGeom undefined references, as that (from Spack) was built with cuda_arch=35?

@sethrj
Copy link
Member

sethrj commented Oct 14, 2020

Could be -- I think the spack environment file in the repo is constructed for our older test machine (which has version 3.5).

@sethrj sethrj added core Software engineering infrastructure minor Minor internal changes or fixes labels Feb 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Software engineering infrastructure minor Minor internal changes or fixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants