You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_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.
Activity
zultron commentedon Dec 31, 2021
CMake build system switch: PR #349
Switch Machinekit APT repo
Switch Machinekit APT repo
Switch Machinekit APT repo
ebo commentedon Jan 5, 2022
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?
cerna commentedon Jan 20, 2022
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_pathfunction (something like thepathliblibrary 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.20or3.21. Basically it is simple to test it and see if it breaks.ebo commentedon Jan 20, 2022
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).
cerna commentedon Jan 20, 2022
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.ebo commentedon Jan 20, 2022