[cmake] Use SIRIUS namespace convention for options and other SIRIUS …

[mtaillefumier]

• 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.

[simonpintarelli]

Do we need the namespaces in the options? Isn't this only an advantage if the project is included as subdirectory?
I'd rather have the fortran api with improved linking, e.g. almost everything internal can be made private, which means we could almost delete siriusConfig.cmake.

[mtaillefumier]

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.

[simonpintarelli]

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 USE_XXX etc don't show up in the installation directory lib/cmake. In siriusConfig.cmake the options are substituted with the value before installation, therefore it's unclear to me what is the benefit of the namespace.

For the Fortran API I don't mean to retire cmake config, just correctly declaring the dependencies, at the moment anything is public.

[mtaillefumier]

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.

[simonpintarelli]

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 USE_CUDA. E.g. my assumption is that in-tree build of SIRIUS is a bad idea and not used anywhere.

[mtaillefumier]

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. -DUSE_MKL might mean something different for dependency A and B and might trigger branches in their respective header files that might only be supported if the dependencies A and/or B are compiled with the relevant flags. That's why for instance compilation dependent flags should avoid __NAME because __NAME is usually reserved to compilers.
Namespacing

[mtaillefumier]

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 USE_XXX etc don't show up in the installation directory lib/cmake. In siriusConfig.cmake the options are substituted with the value before installation, therefore it's unclear to me what is the benefit of the namespace.

well we do things properly but other do not. ;)

For the Fortran API I don't mean to retire cmake config, just correctly declaring the dependencies, at the moment anything is public.

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.

[simonpintarelli]

lgtm

[simonpintarelli]

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.