Cmake version and CI python version upgrades

[varunagrawal]

• update CMAKE version to 3.22 to support Ubuntu 22.04
• use uv to install dependencies
• switch to different runners and bumpy python range by 1

[ProfFan]

some nitpicks

[ProfFan]

3.30 is really really new

[varunagrawal]

Cmake is currently on version 4. Plus I figured this is more for our internal use anyway.

[dellaert]

Could we use whatever we currently use in GTSAM? Same goes for CI runners, btw. Otherwise we could get in a situation where we use something here that is not yet supported in GTSAM.

[ProfFan]

Yeah, CMake will default to use the cmake config provided by upstream package even with FindBoost, see https://cmake.org/cmake/help/v3.10/module/FindBoost.html#boost-cmake

So we don't need to bump the minimum requirement, just need to have a test for the existence of the CMP rule and set it to NEW if exists to silence the warning

[varunagrawal]

I've made that change in GTSAM and was going to push it along with some other minor fixes.

(CMake had been yelling at me a lot recently)

[ProfFan]

Main project is at 3.9 right now https://github.com/borglab/gtsam/blob/develop/CMakeLists.txt

[dellaert]

Asking for too new a version imposes a burden on our users. What is the default version installed for Ubuntu 22 and 24? What is the version in brew and whatever windows uses (Unix subsystem uses Ubuntu). That is what should drive this.

[varunagrawal]

Main project is at 3.9 right now borglab/gtsam@develop/CMakeLists.txt

I made that change locally, I haven't pushed it yet since I am trying to verify dependencies.

[varunagrawal]

I don't have the bandwidth to deal with this (IMO trivial) issue, so I dropped the version down to 3.19.2 since that version is when CMake started supporting Apple Silicon.

(I say trivial since I already spent the time compiling and testing compatibility already before making the PR, as a good contributor would)

[dellaert]

To approve I would need a rationale for minimum cmake version that aligns with GTSAM along the lines of my comment.

[varunagrawal]

To approve I would need a rationale for minimum cmake version that aligns with GTSAM along the lines of my comment.

The main reasons here are:

1. GTSAM doesn't depend on wrap, rather it's the other way around. A Cmake version bump won't affect GTSAM compilation.
2. Given the amount of activity on wrap and the issues raised around it in the GTSAM repo, it seems like almost no one is compiling the wrapper. For those using Python, they are using the version off of PyPI.
3. I manually verified the wrapper compiles with this version of the code on GTSAM.

Regarding supported versions:

• Ubuntu comes default with 3.28.3, and allows an upgrade to 3.31.
• brew installs version 4.2.0.

[varunagrawal]

Also CMake 3.10 is deprecated so I am not a fan of using 3.9 either.

[dellaert]

I thought we included wrap as a subtree inside GTSAM? So, whatever version we impose, should we not synchronize? I don't know why this is a trivial issue. Maybe you and I @varunagrawal should chat about it rather than trying to resolve via comments etc - I might not see the full picture here.

[varunagrawal]

I thought we included wrap as a subtree inside GTSAM? So, whatever version we impose, should we not synchronize? I don't know why this is a trivial issue. Maybe you and I @varunagrawal should chat about it rather than trying to resolve via comments etc - I might not see the full picture here.

It's not necessary to synchronize CMake versions since the only thing CMake is doing is pulling in some variables from GTSAM which are version agnostic. The main compatibility comes with binary level interfacing which is what pybind11 is responsible for.

Also, like I mentioned above, I've already tested the whole pipeline of wrap, compile and testing of the Python wrapper within GTSAM using all these changes. I made the PR after verifying everything works well.