Update GH Actions CI

[ahornung]

• Add single package builds
• Install Qt5 dependencies

[ahornung]

@roehling I added single package builds (octomap, octovis, dynamicEDT3d) to the CI config as separate. For them to succeed I needed to add the HINTs to find the built octomap package within the distribution, as it was done before your changes in #439. Are these changes (990aea6 50a2916) fine, or is there a better way to solve this with CMake?

[roehling]

Instead of hardcoding the CI path in the HINTS, I would add an install step for a common local install tree and point the CMAKE_PREFIX_PATH variable there, so find_package() will use them:

export CMAKE_PREFIX_PATH=${{ steps.strings.output.common-install-dir }}
cmake -S ${{ github.workspace }}/octomap -B ${{ steps.string.output.octomap-build-dir }} -DCMAKE_INSTALL_PREFIX=${{ steps.strings.output.common-install-dir }} ...
cmake --build ${{ steps.string.output.octomap-build-dir }}
cmake --install ${{ steps.string.output.octomap-build-dir }}

[ahornung]

@roehling , thanks! It's not fully hardcoded as a relative path, is it? My intention was to have the same steps in the CI as a user would do locally when compiling the three packages - unless that's not really how it's supposed to be used. Or should that really always happen with local install tree?

[roehling]

Sorry, my last reply has been a while.

Regarding what users do, there are (in my experience) three "canonical" ways to use octomap (or any other CMake-built library):

1. Install the pre-packaged version from your favorite Linux distribution.
   • Advantage: Easy install, easy upgrade.
   • Disadvantage: Usually somewhat outdated version, almost never the latest release.
2. Build and install manually. You can even use a non-standard install prefix like ROS does (/opt/ros/...) if you are comfortable with setting the CMAKE_PREFIX_PATH environment variable.
   • Advantage: find_package() works as with the distributed package.
   • Disadvantage: Uninstalling and upgrading can be a chore.
3. Vendor the source. Just add the octomap source tree as a subdirectory to your own project, either by copying it there or using Git modules. Then add_subdirectory(octomap).
   • Advantage: Full control over the build, no find_package() needed, just use the targets.
   • Disadvantage: You always need to (re-)build the library.

My suggested CI workflow emulates solution 2. The normal "integrated" build workflow is equivalent to solution 3.
You could do both in CI, with some toy "Hello world" program that is built against octomap, to ensure that the build workflows stay functional.