Skip to content
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

Open
zultron opened this issue Dec 31, 2021 · 6 comments
Open

CMake compatibility #361

zultron opened this issue Dec 31, 2021 · 6 comments

Comments

@zultron
Copy link
Contributor

zultron commented Dec 31, 2021

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
Copy link
Contributor Author

zultron commented Dec 31, 2021

CMake build system switch: PR #349

zultron added a commit to zultron/hal_ros_control that referenced this issue Jan 1, 2022
Temporarily switch to Zultron's (my) "stable" APT repo while upstream
CMake issues are worked out.

machinekit/machinekit-hal#361
zultron added a commit to zultron/hal_ros_control that referenced this issue Jan 2, 2022
Temporarily switch to Zultron's (my) "stable" APT repo while upstream
CMake issues are worked out.

machinekit/machinekit-hal#361
zultron added a commit to zultron/hal_ros_control that referenced this issue Jan 3, 2022
Temporarily switch to Zultron's (my) "stable" APT repo while upstream
CMake issues are worked out.

machinekit/machinekit-hal#361
@ebo
Copy link

ebo commented 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
Copy link
Contributor

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

@ebo
Copy link

ebo commented 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
Copy link
Contributor

cerna commented Jan 20, 2022

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
Copy link

ebo commented Jan 20, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants