bump cmake requirement for 5.0
We have a bunch of workarounds for broken 2.8.x versions of CMake, and we sometimes use features that were introduced during their 2.8.x cycle. We should bump our requirement for GROMACS 5.0 so that some of these workarounds can go away.
I think the big useful feature we want is that 2.8.8 provides reliable compiler version number detection, which we use quite a bit for detecting broken compilers.
At the same time we don't want to force everybody to bump their CMake versions. Anybody who installed the latest CMake at the time of the 4.6 betas got at least 2.8.10.
I did a survey (reported on gmx-developers) and found that of the Linux distros that came to mind (plus macports) there was 2.8.9 or 2.8.10 available in all. Ubuntu LTS is still 2.8.7.
We have at least one known bug in 2.8.7 (only) with add_library(). That restricts how we can implement our self-built FFTW, so I would suggest choosing 2.8.7 is probably not a good idea.
2.8.8 is reasonable and conservative. 2.8.10 is also reasonable - will be ~15 months at the time we release GROMACS 5.0.So I propose
- CMake 2.8.8 as the minimum requirement for GROMACS 5, and
- this is fixed until it is time to reconsider for the subsequent major release of GROMACS
I'm prepared to consider 2.8.10 if there's a good reason for it. :-)
Bump CMake requirement to 2.8.8
Permits use of CMake "object libraries," and CMake-based detection of
compiler ID and version. Avoids bug in add_library(GLOBAL). Various
minor CMake logic simplifications ensue.
2.8.8 will be 21 months old by the time we release GROMACS 5. Anybody
who installed the latest CMake since we released 4.6 betas already has
a suitable version. Most distros already supply a higher version, with
the notable exception of Ubuntu 12.04 LTS (supplies 2.8.7). A new
Ubuntu LTS is due shortly after GROMACS 5.0, and it will have a
Also moved the code supporting storing the compiler info in
buildinfo.h to where it is first used, instead of some point in
top-level CMake scope.
#2 Updated by Teemu Murtola over 7 years ago
IIRC, CMake 2.8.8 also adds add_library(... OBJECT), which could help significantly in writing a robust build system for src/gromacs/ without having all the logic in the top-level CMakeLists.txt. Currently, we can't put all the logic for a subdirectory into its CMakeLists.txt, because some need to go to the level where the add_library call is. And file names work quite unintuitively in the current approach.
#3 Updated by Mark Abraham over 7 years ago
2.8.8 does add that, and it seems like we would find uses for
add_library(name OBJECT ...). Basically it creates a virtual library that can be referred to elsewhere in the build system. I'm keen for anything that offers the possibility of more CMake modularity.
#4 Updated by Mark Abraham about 7 years ago
In fact, I think we need the object libraries, because we need to be able to compile test binaries that are linked against both libgromacs and things like the gmx and mdrun code that does not live in libgromacs. Repeatedly specifying the source files means they get recompiled for each executable target, and that is not acceptable. Constructing mini-libraries for those files is workable, but might pollute the top-level make namespace with targets we do not want to build, and would be a pain to work out how to pass both source files and library targets to cmake helper functions like gmx_add_unit_test (but you can use source files and object libraries with add_executable()!).