CMake/LAPACK/BLAS: removed customized/diverged standard modules #931
Conversation
|
unrelated question: |
I think so. Perhaps @oschuett can shed some light on the timeline? I think CMake and Spack packages can still use a bit more time. For instance, I started polishing Spack packages for DBCSR and CP2K. Regarding CMake, I think CP2K's custom modules for all LAPACK/BLAS shall go away for same reasons like this PR. While I am nearly complete with Spack packages, I have only started today with the mentioned removal for CP2K. |
- Related: cp2k@f9dca07 - Changes like picking the correct OpenBLAS threading layer must be upstreamed (CMake). - It can be considered micro-management to prevent inconsistent choices/pickup. - Spack solves this with threads=openmp variant and prevents inconsistency. - Current CMakeFile, standard modules, and Spack are "good enough".
|
RPM builds are failing because of:
This seems to be specified in |
|
@dev-zero FYI, I will soon PR a revised Spack recipe for LIBINT. Would you be so kind and review it as well? |
|
@alazzaro let's get this reviewed on a finite timeline. On an alternative path, you can pre-release DBCSR in anticipation of an upcoming release of CP2K. @alazzaro @oschuett I think, this sort of coupling can drop going forward as soon as the build systems consolidate in CP2K (gmake vs cmake), and as soon as Spack adoption is covering the classic Toolchain. On a side note, I am working on Spack recipes for CP2K and DBCSR as well as important dependencies like LIBINT and LIBXC to ensure performance and satisfaction carries forward from GNU Make and Toolchain. |
Given the current schedule for the next CP2K release (cp2k/cp2k#4249 (comment)), it would be impossible to make a new release and validate it in CP2K in a week. On the other hand, DBCSR is now an external dependency so we will make a new release at our convenience. Considering this PR, I would like to understand if the concerns in #890 are now solved? |
Uh oh!
There was an error while loading. Please reload this page.