Export plugin path in cmake so that we dont need to rely on ament/dsvs

[arjo129]

Desired behavior

A few weeks ago, @luca-della-vedova and I were having a chat about external projects that create custom plugins and worlds. We probably should add an export_plugin and install_model_path to make it easier for people to build colcon projects that rely on custom out of tree plugins. Currently, most packages either rely on ament or on colcon hooks to solve this problem. While ament is one solution, it does require that the project also be dependent on ros2. Colcon hooks, while very powerful are relatively undocumented and cumbersome to use as it requires multiple files. Ideally these macros would generate the desired hooks and export the correct IGN_GAZEBO_RESOURCE_PATH, IGN_GAZEBO_SYSTEM_PLUGIN_PATH and maybe even IGN_LAUNCH_*_PATH.

Alternatives considered

One alternative is to set up a template repo with hooks and push the management downstream to users

[chapulina]

most packages either rely on ament or on colcon hooks to solve this problem

I'll just add some links here as reference:

• ament_environment_hooks.cmake function that generates hooks from templates and installs them.
• colcon.pkg documentation, these files can be used to point to hooks for non-(ament? ROS 2?) projects

While ament is one solution, it does require that the project also be dependent on ros2.

I believe technically this is not true, I think ament is meant to be a project upstream of ROS 2, even though it is tightly connected to it. The main difficulty for us to use it for Ignition may be that it isn't released for the platforms we care about.

to make it easier for people to build colcon projects

I think it's a good idea to provide convenient macros, but I'd like to point out that colcon is just one of the tools that can be used to compile Ignition. So whatever we do, we should try to support the plain-cmake use case as well.

Ideally these macros would generate the desired hooks

I think the macros could be very valuable if they automatically installed the resources to standard places and generated the hook from that. For example:

# Install models and worlds
ign_add_resources(/path/to/models)
ign_add_resources(/path/to/worlds)

# Build and install ign-gazebo system plugins
ign_gazebo_add_system(/path/to/directory/with/system1)
ign_gazebo_add_system(/path/to/directory/with/system2)

# We could have equivalents for different plugin types, config files, etc
# ...

# Generate and install a hook using information from above, without even needing to create a template manually
ign_environment_hook()

One alternative is to set up a template repo with hooks and push the management downstream to users

I think that some documentation and examples may go a long way here. The work needed to generate and install the hooks is just 2 commands:

1. Use configure_file to populate the hook with correct values at build time
2. install the resulting hook

As a reference, here's an example of a pure CMake package that generates a hook:

• setup.sh.in
• configure and install
• executable that sources the installed file (just a convenient wrapper so the user doesn't need to remember to source the setup file)

We could add an example like that to ign-cmake/tutorials, for example.

[osrf-triage]

This issue has been mentioned on Gazebo Community. There might be relevant details there:

https://community.gazebosim.org/t/gsoc-2022-tools-for-creating-new-ignition-projects/1321/1

[harshmahesheka]

I wanted to work on this issue.I think we can have the following macros-
1.ign_add_resources(/path/to/models_or_world)-This will install all the models inside the mentioned folder and add required paths in hooks.
2.ign_add_plugins(/path/to/plugin)-This will add all the plugins inside the mentioned folder as libraries, install them and add required paths in hooks. We can have an option for adding common target_link_libraries , dependencies, etc., and an option if you want to add something to some specific plugin from the folder.
3.ign_add_examples(/path/to/example)-This will be similar to the last one, just instead of libraries; this will add files as executables.
4.ign_add_tests(/path/to/tests)-First, we can add macros for gtest for the non-amnet package(basically a counterpart to ament_cmake_gtest), and then similar to the last 2, this will build all the tests inside the directory with options to add common and specific dependencies.

[Aryaman22102002]

I had previously contributed on a pull request on the ros_ign repository. What more steps should I follow for the "Tools for creating new ignition projects" project in GSOC 2022? I commented here as this issue is related to the project that I mentioned.

[arjo129]

Hi @Aryaman22102002, glad to see your interest. As @harshmahesheka also wants to work on this for GSoC there are two ways to proceed:

• If you really, really, really want to work on this you may submit a proposal to https://community.gazebosim.org/. Note that you will be competeing against another proposal and only one will be selected for GSoC. Of course you can still contribute towards the development of the tool, but it will not be considered for GSoC.
• Alternatively you could pick some other project which interests you on the list or look at some of the tasks labelled help wanted or oobe and propose a project on gazebo discourse. Note that projects marked OOBE also are focussed on improving usability of ignition gazebo.