machinekit-hal
machinekit-hal copied to clipboard
CMake compatibility
The recent switch to CMake requires v. 3.22. A project I'm working on is based on Focal, which ships CMake v. 3.18.
I'm submitting this issue mainly for tracking from the other project, where the temporary fix is a pre-CMake build fork of Machinekit.
CMake build system switch: PR #349
I too was curious why 3.22 was chosen, while on many different platforms 3.166, 3.18, and maybe 3.21 are listed as stable. Was there some feature in 3.22 which made it desirable to use an not-yet-stable version of cmake?
The quick answer is the most simple one: Old fashioned laziness and comfort of development.
Also, I have been using the pre-built staticelly linken binaries from Kitware (in Docker images) and the Snaps (maintained by a core CMake developer, so pretty much always up to date) and the Wheels for building Python extensions (which are mostly up to date too).
From what I can tell, the biggest dependency on later releases is the cmake_path function (something like the pathlib library from Python) for path manipulation. Then, maybe, some bugfixes.
I think it - in theory - could be possible to lower the required version to a 3.20 or 3.21. Basically it is simple to test it and see if it breaks.
Fair enough. As a note, I temporarily dropped it to 3.18 (which is what is supplied with Bullseye, IIRC), and there was much breakage... If we cannot backport to 3.16 or 3.18 the latest stable version) then it might just been something that we need to live with. It will be this weekend the earliest I can poke at anything like that (unless an hour of time magically opens up).
Yeah, the cmake_path was added in 3.20, the rest I am not sure but I seem to remember there were additional changes (or function signatures differences).
One option I was thinking about was to compile and add the CMake package to Machinekit's Debian repository. (Just one statically linked .deb package, not the multi-package solution Debian itself uses.) It - in theory - could be straightforward.
I was thinking of suggesting the same. And as you say, in theory it should be straight forward. If we get that in order, I think there was one other source package build that was needed. That would simplify end users getting a Hello World working.
On Jan 20 2022 4:49 PM, cerna wrote:
Yeah, the
cmake_pathwas added in3.20, the rest I am not sure but I seem to remember there were additional changes (or function signatures differences).One option I was thinking about was to compile and add the CMake package to Machinekit's Debian repository. (Just one statically linked
.debpackage, not the multi-package solution Debian itself uses.) It
- in theory - could be straightforward.