4 ms·

I think parent is referring to the fact that for many Linux distributions, you must build packages with the version of CMake they have in the repositories. Eve

by krapht 5y ago

I think parent is referring to the fact that for many Linux distributions, you must build packages with the version of CMake they have in the repositories. Even today, in 2021, I have to use CMake 2.8.12 / GCC 4.8.5 in order to build code that will deploy on a CentOS 7 server. That means I have to backport the CMake file of every dependency that declares a minimum_requirement of 3+.

mathstuf 5y ago
If you want to be in that distro repo, yeah. If you're just building on CentOS 7, download newer binaries (https://github.com/Kitware/CMake/releases https://github.com/Kitware/CMake/releases) and use them instead. I do this all the time for our CentOS 7 deployments (and we use gcc 8 or 9; I forget when we last uplifted the devtoolset). FWIW, `cmake3` is packaged in CentOS 7 (though it might be EPEL?). All that said, given CMake's backwards compatibility guarantees, it is a bit silly that distributions don't update CMake more aggressively.
- enriquto 5y ago
  > it is a bit silly that distributions don't update CMake more aggressively. this would actually worsen the problem. Main issue is the message "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake" that appears so often when compiling older codes (not that old, written three or four years ago). When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly and then you have to spend a very romantic afternoon with the build system and its beautiful language. Backwards compatibility. You keep using that word. I do not think it means what you think it means.
  - mathstuf 5y ago
    "Future version" will have lots of fanfare before that actually happens. There's no timeline for it; it's a warning that, eventually, we will have to drop old behaviors because otherwise we're stuck with terrible behaviors forever. I mean look at the kinds of things we still support (https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html#manual:cmake-policies(7) https://cmake.org/cmake/help/latest/manual/cmake-policies.7....): - CMP0010 is there to allow projects which did `${var` to "work"; it is an error today - CMP0038 bans `target_link_libraries(tgt tgt)` - CMP0053 gives a *much* faster variable expansion engine at the expense of no longer expanding `@var@` in regular CMake code And it's only with projects using pre-2.8.12 behaviors of policies that actually care about that. If the project is policy-warning clean (except for the policies we cannot realistically warn on, but these are obscure in practice), then you're already compatible. For the record, the old behaviors we cannot warn about because detecting reliance on the old behavior is nigh impossible in practice: - CMP0025: Xcode's `clang` now reports its compiler id as `AppleClang` (due to different versioning schemes); we cannot track if this behavior is used - CMP0047: Same thing for `qcc` on QNX to use the `QCC` compiler id - CMP0056: `try_compile` uses link flags - CMP0060: obscure Unix platform implicit link directory order shenanigans (HP-UX at least) - CMP0061: Remove the implicit `-i` flag to `make` when doing `cmake -build` - CMP0065: executables now need to explicitly export symbols if wanted (was implicit) - CMP0066: `try_compile` now supports per-config flags (instead of only `CMAKE_<LANG>_FLAGS`) - CMP0067: `try_compile` forwards language standard flags through - CMP0073: removal of `_LIB_DEPENDS` cache variables (an implementation detail that got into the cache due to historical decisions) - CMP0082: install rules now happen in declaration order (used to be depth-first order) - CMP0088: `FindBISON`'s CMake API now uses `${CMAKE_CURRENT_BINARY_DIR}` instead of the source directory - CMP0089: compiler id change for IBM's clang-based xlc compilers: `XLClang` - CMP0090: `export(PACKAGE)` default behavior change - CMP0091: MSVC runtime flags are now an abstraction (instead of baked into `CMAKE_<LANG>_FLAGS_<CONFIG>`) - CMP0092: MSVC warning flags are removed from `CMAKE_<LANG>_FLAGS` (to avoid having to `string(REPLACE)` if one wanted to change them) - CMP0093: `FindBoost` version reporting format - CMP0094: `FindPython*` search behavior changes (used to prefer the newest Python over a specific one) - CMP0096: Version numbers with leading zeros are preserved (instead of `21.05` being stripped to `21.5`) - CMP0097: `ExternalProject` handling of git submodules - CMP0098: `FindFLEX` change to mirror `FindBISON` above - CMP0099: link usage interfaces (options, directories, depends) are pushed through linking to static libraries privately (just like linking was) - CMP0101: `target_compile_options(BEFORE)` works on all visibilities (instead of ignoring it in `PRIVATE`) - CMP0102: `mark_as_advanced` no longer wrecks havoc with local variables - CMP0105: link options now apply to the device linking step (CUDA) - CMP0107: `ALIAS` target cannot shadow existing targets - CMP0108: rejects `target_link_libraries(tgt alias_of_tgt)` - CMP0112: relaxes target dependencies when generator expressions are used - CMP0113: internal Makefiles generator fixes to avoid running custom commands multiple times - CMP0116: Ninja generator transformation of `add_custom_command(DEPFILE)` contents to match CMake's usage of paths in the `build.ninja` file - CMP0117: MSVC doesn't get the `/GR` flag from `CMAKE_CXX_FLAGS` by default - CMP0118: any directory can now ask if a source is `GENERATED` - CMP0119: the `LANGUAGE` source file property now selects the compiler to use - CMP0124: `foreach` now removes loop variables at the end of the loop - CMP0125: cache variable handling of `find_X` commands regardless of existing definitions of the variable - CMP0126: `set(CACHE)` no longer removes local variables of the same name If you're using these, yes, we've changed behavior on you. If not, we warn when you have a problem. If you have evidence to the contrary, please file issues. > When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly File bugs. We obviously can't catch everything, but if someone waits 3 years to tell us about a problem, there's obviously nothing we can do about all the releases in between. Behavior regressions are considered serious faults. > Backwards compatibility. You keep using that word. I do not think it means what you think it means. CMake tries extremely hard to keep compatibility with old behaviors when requested. If you file issues about concrete issues instead of just hand waving, then we can do things about it.
jcelerier 5y ago
Why are you inflicting this to yourself ? Centos 7 has GCC 9 and cmake 3.16 (last I checked) in its repos. Personally I build my own software against cmake 3.20 and clang-12 and they work fine on centos 7.

by krapht 5y ago

mathstuf 5y ago

If you want to be in that distro repo, yeah. If you're just building on CentOS 7, download newer binaries (https://github.com/Kitware/CMake/releases https://github.com/Kitware/CMake/releases) and use them instead. I do this all the time for our CentOS 7 deployments (and we use gcc 8 or 9; I forget when we last uplifted the devtoolset). FWIW, `cmake3` is packaged in CentOS 7 (though it might be EPEL?). All that said, given CMake's backwards compatibility guarantees, it is a bit silly that distributions don't update CMake more aggressively.

enriquto 5y ago
> it is a bit silly that distributions don't update CMake more aggressively. this would actually worsen the problem. Main issue is the message "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake" that appears so often when compiling older codes (not that old, written three or four years ago). When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly and then you have to spend a very romantic afternoon with the build system and its beautiful language. Backwards compatibility. You keep using that word. I do not think it means what you think it means.
- mathstuf 5y ago
  "Future version" will have lots of fanfare before that actually happens. There's no timeline for it; it's a warning that, eventually, we will have to drop old behaviors because otherwise we're stuck with terrible behaviors forever. I mean look at the kinds of things we still support (https://cmake.org/cmake/help/latest/manual/cmake-policies.7.html#manual:cmake-policies(7) https://cmake.org/cmake/help/latest/manual/cmake-policies.7....): - CMP0010 is there to allow projects which did `${var` to "work"; it is an error today - CMP0038 bans `target_link_libraries(tgt tgt)` - CMP0053 gives a *much* faster variable expansion engine at the expense of no longer expanding `@var@` in regular CMake code And it's only with projects using pre-2.8.12 behaviors of policies that actually care about that. If the project is policy-warning clean (except for the policies we cannot realistically warn on, but these are obscure in practice), then you're already compatible. For the record, the old behaviors we cannot warn about because detecting reliance on the old behavior is nigh impossible in practice: - CMP0025: Xcode's `clang` now reports its compiler id as `AppleClang` (due to different versioning schemes); we cannot track if this behavior is used - CMP0047: Same thing for `qcc` on QNX to use the `QCC` compiler id - CMP0056: `try_compile` uses link flags - CMP0060: obscure Unix platform implicit link directory order shenanigans (HP-UX at least) - CMP0061: Remove the implicit `-i` flag to `make` when doing `cmake -build` - CMP0065: executables now need to explicitly export symbols if wanted (was implicit) - CMP0066: `try_compile` now supports per-config flags (instead of only `CMAKE_<LANG>_FLAGS`) - CMP0067: `try_compile` forwards language standard flags through - CMP0073: removal of `_LIB_DEPENDS` cache variables (an implementation detail that got into the cache due to historical decisions) - CMP0082: install rules now happen in declaration order (used to be depth-first order) - CMP0088: `FindBISON`'s CMake API now uses `${CMAKE_CURRENT_BINARY_DIR}` instead of the source directory - CMP0089: compiler id change for IBM's clang-based xlc compilers: `XLClang` - CMP0090: `export(PACKAGE)` default behavior change - CMP0091: MSVC runtime flags are now an abstraction (instead of baked into `CMAKE_<LANG>_FLAGS_<CONFIG>`) - CMP0092: MSVC warning flags are removed from `CMAKE_<LANG>_FLAGS` (to avoid having to `string(REPLACE)` if one wanted to change them) - CMP0093: `FindBoost` version reporting format - CMP0094: `FindPython*` search behavior changes (used to prefer the newest Python over a specific one) - CMP0096: Version numbers with leading zeros are preserved (instead of `21.05` being stripped to `21.5`) - CMP0097: `ExternalProject` handling of git submodules - CMP0098: `FindFLEX` change to mirror `FindBISON` above - CMP0099: link usage interfaces (options, directories, depends) are pushed through linking to static libraries privately (just like linking was) - CMP0101: `target_compile_options(BEFORE)` works on all visibilities (instead of ignoring it in `PRIVATE`) - CMP0102: `mark_as_advanced` no longer wrecks havoc with local variables - CMP0105: link options now apply to the device linking step (CUDA) - CMP0107: `ALIAS` target cannot shadow existing targets - CMP0108: rejects `target_link_libraries(tgt alias_of_tgt)` - CMP0112: relaxes target dependencies when generator expressions are used - CMP0113: internal Makefiles generator fixes to avoid running custom commands multiple times - CMP0116: Ninja generator transformation of `add_custom_command(DEPFILE)` contents to match CMake's usage of paths in the `build.ninja` file - CMP0117: MSVC doesn't get the `/GR` flag from `CMAKE_CXX_FLAGS` by default - CMP0118: any directory can now ask if a source is `GENERATED` - CMP0119: the `LANGUAGE` source file property now selects the compiler to use - CMP0124: `foreach` now removes loop variables at the end of the loop - CMP0125: cache variable handling of `find_X` commands regardless of existing definitions of the variable - CMP0126: `set(CACHE)` no longer removes local variables of the same name If you're using these, yes, we've changed behavior on you. If not, we warn when you have a problem. If you have evidence to the contrary, please file issues. > When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly File bugs. We obviously can't catch everything, but if someone waits 3 years to tell us about a problem, there's obviously nothing we can do about all the releases in between. Behavior regressions are considered serious faults. > Backwards compatibility. You keep using that word. I do not think it means what you think it means. CMake tries extremely hard to keep compatibility with old behaviors when requested. If you file issues about concrete issues instead of just hand waving, then we can do things about it.

jcelerier 5y ago

Why are you inflicting this to yourself ? Centos 7 has GCC 9 and cmake 3.16 (last I checked) in its repos. Personally I build my own software against cmake 3.20 and clang-12 and they work fine on centos 7.