Task #3290

Task #3047: Set required versions for GROMACS 2021

Require CMake >= 3.12

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

Target version:


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.



Associated revisions

Revision c822506c (diff)
Added by Paul Bauer about 1 month 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


#1 Updated by Szilárd Páll about 1 month 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 about 1 month 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.
- more and smarter source-file-level properties (INCLUDE_DIRECTORIES, COMPILE_OPTIONS, etc)
- more commands for list(), string(), and file()
- <PackageName>_ROOT for find_package()
- 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 about 1 month ago

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

#4 Updated by Mark Abraham about 1 month 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 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.

Also available in: Atom PDF