-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMake compatibility #361
Comments
CMake build system switch: PR #349 |
Temporarily switch to Zultron's (my) "stable" APT repo while upstream CMake issues are worked out. machinekit/machinekit-hal#361
Temporarily switch to Zultron's (my) "stable" APT repo while upstream CMake issues are worked out. machinekit/machinekit-hal#361
Temporarily switch to Zultron's (my) "stable" APT repo while upstream CMake issues are worked out. machinekit/machinekit-hal#361
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 I think it - in theory - could be possible to lower the required version to a |
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 One option I was thinking about was to compile and add the CMake package to Machinekit's Debian repository. (Just one statically linked |
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.
|
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.
The text was updated successfully, but these errors were encountered: