Convenience CMake for Gazebo Metapackage

[osrf-migration]

Original report (archived issue) by Michael Carroll (Bitbucket: Michael Carroll, GitHub: mjcarroll).

---

Based off of discussion over on ros_ign github, it may make sense to create some CMake logic that would allow a one-shot configuration of multiple ignition packages.

We could replace logic like this:

  find_package(ignition-gazebo3 REQUIRED)
  set(IGN_GAZEBO_VER ${ignition-gazebo3_VERSION_MAJOR})

  find_package(ignition-transport8 REQUIRED)
  set(IGN_TRANSPORT_VER ${ignition-transport8_VERSION_MAJOR})

  find_package(ignition-msgs5 REQUIRED)
  set(IGN_MSGS_VER ${ignition-msgs5_VERSION_MAJOR})

With something like

find_package(ignition-citadel REQUIRED COMPONENTS gazebo transport msgs)

Which would bring in the required packages and populate the necessary versions for downstream use.

[osrf-migration]

Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

This sounds like a really great idea. However, I think I’d recommend implementing it as a meta-package per release rather than cramming the logic into ign-cmake directly.

In other words, we would have a repo called ignition-citadel which has a very simple CMakeLists.txt that contains information about which ignition packages belong to the citadel release and what their respective versions are.

We could have a function in ignition-cmake that consumes that information and produces the install rules for an appropriate meta-package config-file.

[osrf-migration]

Original comment by Michael Carroll (Bitbucket: Michael Carroll, GitHub: mjcarroll).

---

I agree, that ign-cmake is probably not the place for this to live, but it seemed like the best place to track the idea for the time.

Do you think it would make sense for it to source the information from something like gazebodistro or should it have another copy of the data internally?

‌

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

we would have a repo called ignition-citadel which has a very simple CMakeLists.txt that contains information about which ignition packages belong to the citadel release and what their respective versions are.

You're in luck, that's exactly what we already have, and that's how we've been releasing the ignition-citadel debian package. It's not divided into components yet though.

source the information from something like gazebodistro or should it have another copy of the data internally

We currently have a copy, which is not great.

[osrf-migration]

Original comment by Silvio Traversaro (Bitbucket: traversaro).

---

We currently have a copy, which is not great.

I implemented a really minimal vcstool .repos file parser inpure CMake in https://github.com/robotology/robotology-superbuild/pull/343/files , it extracts different info from the one that you are interested in in this case, but feel free to check it out/copy parts if you find it useful.

[scpeters]

We could replace logic like this:

  find_package(ignition-gazebo3 REQUIRED)
  set(IGN_GAZEBO_VER ${ignition-gazebo3_VERSION_MAJOR})

  find_package(ignition-transport8 REQUIRED)
  set(IGN_TRANSPORT_VER ${ignition-transport8_VERSION_MAJOR})

  find_package(ignition-msgs5 REQUIRED)
  set(IGN_MSGS_VER ${ignition-msgs5_VERSION_MAJOR})

With something like

find_package(ignition-citadel REQUIRED COMPONENTS gazebo transport msgs)

Which would bring in the required packages and populate the necessary versions for downstream use.

more modern example:

# replace the following
find_package(gz-sim8 REQUIRED)
set(GZ_SIM_VER ${gz-sim8_VERSION_MAJOR})

find_package(gz-transport13 REQUIRED)
set(GZ_TRANSPORT_VER ${gz-transport13_VERSION_MAJOR})

find_package(gz-msgs10 REQUIRED)
set(GZ_MSGS_VER ${gz-msgs10_VERSION_MAJOR})

# with this
find_package(gz-harmonic REQUIRED COMPONENTS sim transport msgs)

I would expect this to create the following cmake targets:

• gz-harmonic::sim
• gz-harmonic::transport
• gz-harmonic::msgs

and probably any package dependencies not explicitly requested such as:

• gz-harmonic::cmake
• gz-harmonic::math
• etc

and maybe some version variables like

• gz-harmonic_sim_MAJOR_VERSION

[mjcarroll]

I thought about this before, and to make version changes even easier, I think we could do something like this as a step further:

find_package(gz REQUIRED COMPONENTS gazebo VERSION harmonic)

target_link_libraries(foobar gz::gazebo)

The thing that I actually ran into is how to deal with sub-components, so:

gz::utils::cli   # Ideally
gz::utils-cli  # alternatively?

[scpeters]

The thing that I actually ran into is how to deal with sub-components, so:

gz::utils::cli   # Ideally
gz::utils-cli  # alternatively?

ooh, yeah subcomponents make it tough

also, if these cmake helpers are provided by gz-{collection}, then you would need to have the whole collection installed in order to find even a sub-component (i.e. you need all the dependencies up to gz-launch in order to find_package(gz-harmonic COMPONENTS math))