machinekit-hal icon indicating copy to clipboard operation
machinekit-hal copied to clipboard

CMake compatibility

Open zultron opened this issue 3 years ago • 6 comments

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.

zultron avatar Dec 31 '21 19:12 zultron

CMake build system switch: PR #349

zultron avatar Dec 31 '21 19:12 zultron

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?

ebo avatar Jan 05 '22 17:01 ebo

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.

cerna avatar Jan 20 '22 14:01 cerna

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).

ebo avatar Jan 20 '22 14:01 ebo

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.

cerna avatar Jan 20 '22 21:01 cerna

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_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.

ebo avatar Jan 20 '22 21:01 ebo