> My main portability problem when building packages is the very existence different cmake versions
Why? You should always be able to update CMake and have it continue to work. If not, that's a regression in CMake and we take those very seriously.
Why? You should always be able to update CMake and have it continue to work. If not, that's a regression in CMake and we take those very seriously.
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+.
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.
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.
- 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
- 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
> 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.
CMake hard-codes the absolute path to itself all over the place. Any time a package manager that relies on symlinks (eg homebrew) updates the CMake package, every build that relies on it breaks. (last time that happened I ended up downloading the cmake.org build and recreating the symlinks because I couldn't afford hours of rebuild)
FWIW, CMake is highly relocatable and doesn't really care where it ends up living. That Homebrew removes versions you were using out from under you is not something we can fix. Or maybe I'm not understanding the problem fully (I don't use Homebrew with any consistency to know what the issue is here).