-
Notifications
You must be signed in to change notification settings - Fork 40
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
[cmake] Use SIRIUS namespace convention for options and other SIRIUS … #832
Conversation
mtaillefumier
commented
Apr 25, 2023
•
edited
Loading
edited
- Namespace cmake options.
- Namespace the SIRIUS compilation flags
- The spack recipe is modified to reflect the cmake changes.
- Use the local spack recipe for sirius instead of the official version (We need to update it eventually)
- updated the docker containers for the CI.
- Update the docker containers for app distribution (we should do nothing here)
- Update the spack recipe in the spack repo. Need a PR for this.
Do we need the namespaces in the options? Isn't this only an advantage if the project is included as subdirectory? |
Yes it is actually good practice to have compilation options namespaced. It is done almost everywhere. It is even more important when we install findPackage.cmake modules because variable names is problematic in general. USE_CUDA for instance can be used in project A that depends on SIRIUS (that also has this variable in siriusConfig.cmake) but sirius is compiled without cuda support. Removing the siriusConfig.cmake is out of the table because findPackage(sirius) rely on it to actually find the dependencies needed during linking time (that's also why we need to copy the findPACKAGE.cmake we provide). It would be like using pkgconfig for detecting sirius without actually creating the pc file associated to it. the fortran stuff is decoupled from this. |
I agree it seems the prefixed option names is common. But what is the benefit for SIRIUS? As far as I can see the options For the Fortran API I don't mean to retire cmake config, just correctly declaring the dependencies, at the moment anything is public. |
USE_OPTION can be used by other projects as well which is also common. USE_CUDA for instance is a typical example of this issue and it can have disastrous consequences as we encountered in cosma / costa for instance. I had similar issues when working on cp2k cmake build system. It is unfortunate that cmake does not automatically do this so we have to compensate for this design flaw. |
That's my question, cosma/costa uses in-tree build, but for SIRIUS this is not the case. Thus I don't see the problem of calling the option |
it is a bad idea indeed to build sirius in tree (that's why submodule is also a bad idea). The problem is identical to the DFLAGS in header files provided by different libraries. |
well we do things properly but other do not. ;)
I misunderstood your intend here for the fortran api. I though you were referring to the problem you mentioned yesterday. Indeed everything is public in cmake and I do not know how to make things private by default. I am not even sure it can be done actually. |
fe9667d
to
75b8dfa
Compare
18f30d9
to
b94e6e9
Compare
55a8c9a
to
59ea439
Compare
6e0d115
to
627718c
Compare
68ca5c4
to
1e18c37
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
src/CMakeLists.txt
Outdated
$<$<BOOL:${SIRIUS_USE_MAGMA}>:SIRIUS_MAGMA> | ||
$<$<BOOL:${SIRIUS_USE_ROCM}>:SIRIUS_GPU SIRIUS_ROCM> | ||
$<$<BOOL:${SIRIUS_USE_VDWXC}>:SIRIUS_USE_VDWXC> | ||
$<$<STREQUAL:${SIRIUS_USE_FP32},"ON">:SIRIUS_USE_FP32> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before it defined USE_FP32_BOOL (after checking for single precision support in spfft) in main CMakeLists.txt
. I would rather keep the two variables, e.g. SIRIUS_USE_FP32_BOOL
and SIRIUS_USE_FP32
, instead of using STREQUAL on something which should be a boolean.
…internal variables - updated README.md file to reflect the new convention - updated the spack recipe - removed multiple versions of the spack recipe - updated the docker files when needed - remove unused modules in `cmake/modules`
be38044
to
a090349
Compare