Closed friendlyanon closed 2 years ago
No problem -- I didn't actually test this myself as I don't have cmake installed. My experience with cmake has been that point releases are generally not very compatible with each other, so you'll often need changes between version x.y and x.(y+1).
Thanks for the quick response again!
CMake maintains backwards compatibility with the use of policies, although it won't enforce things unless you actually test with an older version, which I forgot to do.
Something that was written to work with CMake 3.2 will work just as well for CMake 3.22 (which is what I am running).
CMake is also a very portable program. You don't really need to install anything for it. You can just grab an archive, extract anywhere and use it like that. That's how I have older versions to test with for example.
To quote Alex Reinking from his blog:
I can't stress this enough: Kitware's portable tarballs and shell script installers do not require administrator access. CMake is perfectly happy to run as the current user out of your downloads directory if that's where you want to keep it. Even more impressive, the CMake binaries in the tarballs are statically linked and require only libc6 as a dependency. Glibc has been ABI-stable since 1997. It will work on your system.
No problems -- thatnks for the contributions, as they'll probably be useful to some people.
Apologies for the hasty hotfix PR for #27, but I should have tested the build with the CMake version I declared as a minimum. The Conan CI run revealed that my minimum version was not actually correct, because in the
skel2c.cmake
script I used thecontinue()
command, which was actually introduced in CMake 3.2.I have also passed the script in a wrong format, because only
-P
requires its argument to be separate. Quirks of old CMake versions that have fortunately been fixed in more recent versions.