Feature/generic cmake

[nubertj]

I think with the new requirements of being buildsystem independent we have to move away from gtsam_catkin.

Instead I propose:

1. System install (potentially local installation) of gtsam
2. graph_msf as pure cmake package
3. slim graph_msf_catkin to make graph_msf available directly to catkin packages and to still comfortably develop / debug
4. Downstream packages such as graph_msf_ros or smb_estimator_graph then simply use graph_msf_catkin.

For ros2/colcon, which is much closer to cmake, we can see what is the best solution and whether we can avoid having a graph_msf_ament. I think it should also work without.

First running prototype attached to this PR. Happy about any testers on existing data.

[nubertj]

#4 should be merged before

[willat343]

So I don't think I have time to go through the 151 files but through many hours spent on this problem i came to the conclusion that catkin wrappers only provide value for external libraries that don't provide package.xml files (e.g. Open3D) and even then probably one is better off installing the library system-wide or locally as preferred.

As an example, I now have a workflow that is somewhat similar in build complexity containing base dependencies (Eigen3, manif, ceres) which i have installed locally (although i'm considering ExternalProject), and several of my own dependencies (mathbox, sensorbox, convert) which I usually build directly to the workspace with a simple catkin build (convenient while developing) or can be installed locally/system-wide. There is no need for a mathbox_catkin, sensorbox_catkin or convert_catkin as I used to have, and I have no issues with using catkin when the CMake code contains no catkin commands.

Similarly, there is no issue with gtsam or in my case ceres being installed to a workspace if it is there because they provide package.xml files - just include in the workspace and catkin build.

Not only are the catkin Cmake functions unnecessary, I have found then to be limited and the source of many build problems. The insight is that they pass on include directories, link libraries, and with a bit a wrangling, some additional CMake variables. However modern CMake has embraced a much more abstracted target system, such that using find_package(pkg) the normal way (rather than find_package(catkin COMPONENTS pkg)) gives you a target that can have any of the Target Properties set, including include directories, link libraries, compile flags, linker flags, compile-time definitions (and more) in accordance with the requirement of that base library. This is an issue we've discussed before, so I won't go into more detail.

Regarding ament and the colcon build system, I have no idea if the same logic applies.

[nubertj]

Yes but then you should like this PR, no?

For me works super seamlessly, and is nice to develop with this setup as well. The only downside is one can not actively change gtsam anymore, but this is quite realistic in 99% of the use cases I think.

[nubertj]

So I don't think I have time to go through the 151 files but through many hours spent on this problem i came to the conclusion that catkin wrappers only provide value for external libraries that don't provide package.xml files (e.g. Open3D) and even then probably one is better off installing the library system-wide or locally as preferred.

As an example, I now have a workflow that is somewhat similar in build complexity containing base dependencies (Eigen3, manif, ceres) which i have installed locally (although i'm considering ExternalProject), and several of my own dependencies (mathbox, sensorbox, convert) which I usually build directly to the workspace with a simple catkin build (convenient while developing) or can be installed locally/system-wide. There is no need for a mathbox_catkin, sensorbox_catkin or convert_catkin as I used to have, and I have no issues with using catkin when the CMake code contains no catkin commands.

Similarly, there is no issue with gtsam or in my case ceres being installed to a workspace if it is there because they provide package.xml files - just include in the workspace and catkin build.

Not only are the catkin Cmake functions unnecessary, I have found then to be limited and the source of many build problems. The insight is that they pass on include directories, link libraries, and with a bit a wrangling, some additional CMake variables. However modern CMake has embraced a much more abstracted target system, such that using find_package(pkg) the normal way (rather than find_package(catkin COMPONENTS pkg)) gives you a target that can have any of the Target Properties set, including include directories, link libraries, compile flags, linker flags, compile-time definitions (and more) in accordance with the requirement of that base library. This is an issue we've discussed before, so I won't go into more detail.

Regarding ament and the colcon build system, I have no idea if the same logic applies.

btw if you check the PR you would see that it is a very small PR with small changes. Most of the 157 files are just there as I moved the location of the examples (but the examples itself remain unchanged).

[willat343]

You could consider ditching graph_msf_catkin so long as you keep a package.xml in graph_msf

[nubertj]

You could consider ditching graph_msf_catkin so long as you keep a package.xml in graph_msf

This is what I tried in the beginning.
But this created all kind of downstream issues, including linking errors and non standard locations for the include paths.

It worked seamlessly for colcon, which is much closer to cmake, so there is NO graph_msf_ament. See this PR for details: #7