Project

General

Profile

Task #3290

Task #3047: Set required versions for GROMACS 2021

Require CMake >= 3.12

Added by Eric Irrgang 5 months ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Difficulty:
uncategorized
Close

Description

CMake 3.12 is a good release for features and robustness that support cleaner CMakeLists.txt and better user experience. Some of these improvements relate to find_package facilities generally (like <package>_ROOT input variable) and specifically (better Python detection and Python 3 handling). Other improvements include better target_link_libraries support, such as for OBJECT targets. CMake >= 3.12 will have been available in standard Linux distributions for a while by release-2021, but installing CMake is not much of a usability burden in any case.

If we can require 3.12 with the 2021 release, we should move to CMake 3.12 soon (in conjunction with moving our infrastructure to GitLab Runner) so that we can benefit from it for the rest of the 2021 development cycle.

References

- https://cmake.org/cmake/help/git-stage/release/3.10.html
- https://cmake.org/cmake/help/git-stage/release/3.11.html
- https://cmake.org/cmake/help/git-stage/release/3.12.html


Related issues

Related to GROMACS - Task #2505: increase cmake reqirement for GROMACS 2020Closed

Associated revisions

Revision c822506c (diff)
Added by Paul Bauer 4 months ago

Allow access to optional outside libgromacs

When using gmx::compat::option in files also included
outside of the libgromacs tree (e.g. anything topology related),
compilation would abort because the include path could not be resolved
for nonstd::optional.hpp in e.g. legacymodules.cpp or view.cpp.

Adds the information needed to the CMakefiles to always find the correct
include path.

Also modifies CUDA nvcc compilation to have the header available for
those CUDA compiled files that need it.

Should be revisited when resolving #3290

Change-Id: If335ecdfa1bd2ba56cae7ee26c07d9a7faa5a651

Revision ee34898e (diff)
Added by Eric Irrgang about 1 month ago

Require CMake >=3.13.

Fixes #3290

History

#1 Updated by Szilárd Páll 5 months ago

It would be useful to have a concrete list of tasks that the migration enabled including workarounds/imported modules that can be removed as well as new CMake features that we should migrate (either as a one-step conversion or a gradual migration).

#2 Updated by Eric Irrgang 5 months ago

  • Description updated (diff)

I see five existing references to CMake 3.12 in current CMakeLists.txt comments, and it has come up on Gerrit. I think Mark's deep dive into GROMACS CMake infrastructure has probably given him several stories to tell, but I don't see any embedded specifics in the repo right now. If this issue is likely to be unresolved for a while, people can comment or link to it from "to do"s, I suppose, but I think there will continue to be a lot of rearrangement and modernization efforts in the CMake infrastructure this year, and it would be good to know if/when we can count on the new functionality and behaviors.

A few things that jump out at me right now:

- improvements to the GoogleTest module, which we can consider using more.
- FindMPI improvements.
- more CUDA awareness.
- add_library() and add_executable() commands can now be called without any sources and will not complain as long as sources are added later via the target_sources() command.
- https://cmake.org/cmake/help/git-stage/release/3.11.html#commands
- more and smarter source-file-level properties (INCLUDE_DIRECTORIES, COMPILE_OPTIONS, etc)
- more commands for list(), string(), and file()
- <PackageName>_ROOT for find_package()
- https://cmake.org/cmake/help/git-stage/prop_tgt/EXPORT_PROPERTIES.html#prop_tgt:EXPORT_PROPERTIES
- New FindPython3 and FindPython2 modules
- directories marked as SYSTEM now work right on compilers that do not have -isystem
- A new $<IN_LIST:...> generator expression has been added.
- A new $<TARGET_EXISTS:...> generator expression has been added.
- target_compile_options() and add_compile_options() commands gained a SHELL: prefix to specify a group of related options using shell-like quoting.
- The target_link_libraries() command now supports Object Libraries. Linking to an object library uses its object files in direct dependents and also propagates usage requirements.

I added release notes links to the issue description.

#3 Updated by Eric Irrgang 4 months ago

  • Target version changed from 2021-infrastructure-stable to 2021-refactoring

#4 Updated by Mark Abraham 4 months ago

I note that ubuntu 18.04 has only 3.10, and that LTS version will still have appreciable life that overlaps with GROMACS 2021. However, kitware has always provided downloadable binaries, the source is very easy to build, and there's a new kitware apt repo also https://blog.kitware.com/ubuntu-cmake-repository-now-available/. So the above combination of minor advantages seem useful to me.

We have a lot of cruft around coping with the large number of optional build components on a wide range of platforms with CMake support of varying quality, and being able to structure inclusions for object libraries for modules seems like it will help reduce complexity from work-arounds.

Perhaps a good first approach would be to identify how we could improve the handling of e.g. thread-MPI, so that rather than hanging include directories needed for it to global compiler search paths we can declare those for the thread-MPI object library and handle it as a dependency of the few modules that actually need it. Then we have a concrete thing to evaluate against thte inconvenience to users of getting cmake 3.12+

Looking forward, we are likely to acquire another optional dependency on oneAPI, and we need to keep working on the maintainability of the build system.

#5 Updated by Erik Lindahl 3 months ago

IIRC, the requirement we've used is that our CMake version should be supported in the latest LTS releases, and by the time GROMACS-2021 is out, that will be Ubuntu-20.04.

#6 Updated by Mark Abraham 3 months ago

Erik Lindahl wrote:

IIRC, the requirement we've used is that our CMake version should be supported in the latest LTS releases, and by the time GROMACS-2021 is out, that will be Ubuntu-20.04.

ubuntu 18.04 had 3.10.x
ubuntu 20.04 looks like 3.16.3 (https://launchpad.net/ubuntu/focal/+source/cmake)
debian 10 a.k.a buster (the 2019 stable release) has 3.13.4
RHEL 8 has 3.11.4

All those distros have mechanisms to add extra repos to install more recent cmake, as well as Kitware's cmake binaries and easy source compilation. Rolling distros will automatically be ahead of anything we choose to suit the LTS ones.

For 2020, we required cmake 3.9.6 at hhttps://redmine.gromacs.org/issues/2505, so 3.12 would be consistent with that principle. I don't like sliding in over RHEL 8, but people living in that kind of world often have RHEL <8 and EPEL is a thing.

Unless there's some counter-proposals, lets regard 3.12 as the choice. Paul?

#7 Updated by Mark Abraham 3 months ago

  • Related to Task #2505: increase cmake reqirement for GROMACS 2020 added

#8 Updated by Paul Bauer 3 months ago

Lets go with 3.12 then, I also think that people stuck on older versions are stuck there for a reason and usually know how to get more modern tools if the need them.

#9 Updated by Joe Jordan 3 months ago

Perhaps it is too late to weigh in, but I would vote for requiring 3.13 since it will not affect compatibility any more than 3.12 would. One thing that is needed is turning various of the modules into self-contained libraries. This is possible but hard before 3.12 so that should be a hard requirement. However, it will be slightly easier if we require 3.13 for two reasons that are stated in this helpful blog post https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/.

1) Prior to 3.13.0, target_link_libraries() could only be called on a target that was created in the same directory scope.

2) In CMake 3.12 or earlier, relative paths were treated as being relative to the target to which sources were being added.

Neither of these are deal-breakers so if we go with 3.12 we will be able to do everything we want. It will just require more boiler-plate than if we pick 3.13, which is still going to be supported by the platforms we are targeting.

#10 Updated by Mark Abraham 3 months ago

Joe Jordan wrote:

Perhaps it is too late to weigh in, but I would vote for requiring 3.13 since it will not affect compatibility any more than 3.12 would. One thing that is needed is turning various of the modules into self-contained libraries. This is possible but hard before 3.12 so that should be a hard requirement. However, it will be slightly easier if we require 3.13 for two reasons that are stated in this helpful blog post https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/.

1) Prior to 3.13.0, target_link_libraries() could only be called on a target that was created in the same directory scope.

2) In CMake 3.12 or earlier, relative paths were treated as being relative to the target to which sources were being added.

Neither of these are deal-breakers so if we go with 3.12 we will be able to do everything we want. It will just require more boiler-plate than if we pick 3.13, which is still going to be supported by the platforms we are targeting.

Those improvements in 3.13 are indeed useful for our needs, so I'm happy to support 3.13

#11 Updated by Paul Bauer 3 months ago

I'm happy as well with 3.13.0, but would invite people with helping me to port the testing to support it :)

#12 Updated by Mark Abraham 3 months ago

Paul Bauer wrote:

I'm happy as well with 3.13.0, but would invite people with helping me to port the testing to support it :)

We can start by changing the apt-get install cmake in the Dockerfiles to downloading the 3.13.latest binary tarball from Kitware. Later, we parameterize our builds so we use a couple of flavors.

Note that kitware does have an apt repo for cmake, but the earliest they started with was 3.14, so not sure if generally useful for us.

#13 Updated by Eric Irrgang about 1 month ago

  • Status changed from New to Resolved

Also available in: Atom PDF