Closed christophfroehlich closed 10 months ago
Kitware has an apt repo that might make it easier to install newer cmake versions on older linux systems: https://apt.kitware.com/
As to why we are using 22, we started with the assumption that tier 1 platforms were the ones we needed to target. I'm unsure if there are specific cmake features from 22 we used. Have you tried changing the cmake version to see if there is any effect?
With the apt server from kitware it is (at least not directly possible) with debian, the officially only support Ubuntu. But a good hint for ubuntu focal maybe.
$ sudo apt-get install cmake ....
The following packages have unmet dependencies: cmake : Depends: libc6 (>= 2.34) but 2.31-13+deb11u7 is to be installed Depends: libssl3 (>= 3.0.0~~alpha1) but it is not installable Depends: libstdc++6 (>= 12) but 10.2.1-6 is to be installed E: Unable to correct problems, you have held broken packages.
I haven't tested to change the version for building this repo, I'll give that a try.
I’m of two minds about this. If we’re not using any CMake 3.22 features then I’m open to lowering the requirement. However, I’m not keen on maintaining support for Tier 3 platforms when reasonable workarounds exist like using Kitware’s Apt repo or using the prebuilt packages that exist in Humble, Iron, and Rolling. All three distros are shipping the latest release of RSL.
Having the requirement at 3.22 means we’re able to use newer features in the future without anyone’s workflows breaking. Lowing that requirement cuts us off from future opportunities for improvement. Ubuntu 24 is around the corner and will ship with CMake 3.28 (or possibly 3.29) so I’m already looking forward to using even newer CMake features.
I’d like to know a few things:
We had some issues lately with ros2_control, because not the full c++17 standard was implemented with the shipped compilers. I don't have any statistics, but at least two issues were submitted after we merged the suspect PR failing on RHEL 8 and debian 11.
The thing now with CMake is that debian 11 (humble+iron Tier 3) does not have support by the KItware's Apt repo nor are there any prebuilt ROS packages. Correct me if I'm wrong, I'd be happy to have a simpler solution.
I'll test with forking RSL and setting a lower CMake version, but it would be great to not have unmanaged forks in our CI/CD.
Why I'm using debian 11? Because of a 3rd party hardware API, which is officially not released for other platforms and I didn't want to fight hardware access from docker containers in the first place.
I haven't released any ROS packages yet, hence I'm not sure about the additional work: But might it be reasonable to branch for humble/iron with a lower CMake requirement and jazzy/rolling with a newer one?
I changed the required version of RSL to 3.18 and with
$ cmake --version
cmake version 3.18.4
colcon build and colcon test succeeds with the RSL+cpp_polyfills packages, is there anything more to test if it works with v3.18?
A consequence of https://github.com/PickNikRobotics/generate_parameter_library/pull/173 is that one simply can't install it without a newer CMake version.
It seems that there is a simpler way to update CMake on RHEL and debian, just use the binaries from the release on github
RUN \
cd && \
wget https://github.com/Kitware/CMake/releases/download/v3.23.5/cmake-3.23.5-linux-x86_64.tar.gz && \
cd /usr && \
tar --strip-components=1 -xzf ~/cmake-3.23.5-linux-x86_64.tar.gz && \
rm ~/cmake-3.23.5-linux-x86_64.tar.gz
Then this is maybe no issue any more.
This library requires CMake version 3.22 which is not available on Tier 3 platforms of humble or iron
https://github.com/PickNikRobotics/RSL/blob/c582b49de1d0c9691128125269c3c2cb0ead452e/CMakeLists.txt#L1
Is there a good reason for this, or could you possibly lower that to 3.16 (ubuntu focal) or 3.18 (debian 11)?
For example, ros2_control can't be built on debian11 without compiling CMake from source.