spack/spack#48772

It seems Debian/Ubuntu is still on libxc 5.2.3. I guess, it's time to disable it since we now require libxc 7.

@RMeli Just saw this on my Github splash page and thought I'd comment.

Spack packages currently uses autotools therefore upstream changes to support the CMake build system are required

The cmake build system in libxc is still considered experimental. My colleague, Cristian, opened a PR (and 610) to modernise it, however he's now left Hamburg and it's stalled. I tried pinging Lori to reengage, but no response. Ideally we'd (Octopus) like fetchContent support and scoping of cmake variables. Is this something you're also interested in?

Hi @AlexBuccheri, thank you for commenting! I wasn't aware the CMake build system was considered experimental, but it seemed to have everything needed to be usable.
The "upstream changes" I was referring to were for the Spack package manager (i.e. allowing to build libxc with CMake), and not libxc itself.

I agree the scoping of more variables would definitely be good (it's a good practice), but I don't think it is currently an issue for CP2K.

Concerning fetchContent, I personally don't like it . There is some discussion here, for context: #2985 (comment). In short, it is preferred to use a proper package manager (like Spack). If support is added in libxc without breaking other things, why not. But it is not something we will use.

@RMeli

i.e. allowing to build libxc with CMake

This depends on who the maintainer of the spack package is. My general assumption being that if it's Susi or Lori, using autotools as the default build system won't change until cmake is considered stable.

I agree the scoping of more variables would definitely be good (it's a good practice), but I don't think it is currently an issue for CP2K.

There were more changes (maybe not in the MR I linked) concerning packaging, which has implications for all consumers.

There is some discussion here, for context: #2985 (comment)

haha, this is funny. It' Crisitian initiating this discussion. He's now left Octopus and is at QT, but it appears he went on quite a cmake spree in the electronic structure community.

From the discussion

The CP2K build system should not be responsible for building its dependencies (cmake is not a package manager although it has some of these functionalities)

This is exactly what Peter Bygrave used to say, but I'm not so sold on this. Years ago, people used to just absorb essential external dependencies into source, which was clearly bad. But I like the idea that a code should be able to build out of the box with the minimal hard dependencies.

But ok, the fundamental point is that CP2K doesn't require any changes to the existing libxc cmake build system - thanks for the feedback.

This depends on who the maintainer of the spack package is.

I'm the maintainer. =) I added myself because no one else was listed. I added support for CMake in spack/spack#48772. Anyone can contribute to Spack packages via PRs, and I added the possibility to do spack install libxc build_system=cmake from version 7.0.0 onwards (Spack supports packages with multiple build systems, so spack install libxc build_system=autotools will work too). I had a better look, and CMake is indeed rather new, but it is not marked explicitly as "experimental" (as is CUDA support, for example).

There were more changes (maybe not in the MR I linked) concerning packaging, which has implications for all consumers.

If they happen, I'll definitely update the Spack package to reflect changes in libxc CMake.

But I like the idea that a code should be able to build out of the box with the minimal hard dependencies.

While I see the attraction for having this, I think using a proper package manager is generally better. Additionally, libxc is not strictly a hard dependency of CP2K (many of the dependencies are optional in CP2K).

This is my personal opinion and I don't claim to speak for the CP2K community. If someone wants to add proper support and use for fetch_content and make everything work, why not. But it is not something I see as necessary or would be keen to work on. The only thing I'd ask is to have the possibility to turn off completely that possibility (with a CMake variable, for example), so that there is no risk of messing things up when using a proper package manager (to avoid having CP2K install dependencies that the package manager knows nothing about).

The fundamental point is that CP2K doesn't require any changes to the existing libxc cmake build system

This appears to be the case at the moment in the way we use libxc, since find_package is enough and we install libxc using Spack or the CP2K toolchain (which might go away at some point, in favor of using external package managers).