Add gz-sim-yarp-plugins package

[xela-95]

This PR adds the https://github.com/robotology/gz-sim-yarp-plugins package.

Reference issue: robotology/gz-sim-yarp-plugins#131

[xela-95]

@traversaro I was looking how to enable the build of gz-sim-yarp-plugins project to test everything works. This comes with the new option ROBOTOLOGY_USES_GZ that is disabled by default and mutually exclusive wrt ROBOTOLOGY_USES_GAZEBO.

Should I configure an additional step similar to

robotology-superbuild/.github/workflows/ci.yml

Lines 384 to 391 in 5737298

	- name: Configure [Ubuntu]
	if: contains(matrix.os, 'ubuntu')
	shell: bash
	run: |
	cd ${ROBOTOLOGY_SUPERBUILD_SOURCE_DIR}
	mkdir -p build
	cd build
	cmake -C ${ROBOTOLOGY_SUPERBUILD_SOURCE_DIR}/.ci/initial-cache.gh.cmake -G"${{ matrix.cmake_generator }}" -DYCM_EP_ADDITIONAL_CMAKE_ARGS:STRING="-DMatlab_ROOT_DIR:PATH=${GHA_Matlab_ROOT_DIR} -DMatlab_MEX_EXTENSION:STRING=${GHA_Matlab_MEX_EXTENSION}" -DROBOTOLOGY_USES_MATLAB:BOOL=ON -DYCM_BOOTSTRAP_VERBOSE=ON -DNON_INTERACTIVE_BUILD:BOOL=TRUE -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} ${{ matrix.project_tags_cmake_options }} ..

with the ROBOTOLOGY_USES_GZ option set to ON?

[traversaro]

Ah, this thing of mutual exclusivity is complex and is going to be an headache. Until now, the logic in the CI was always: "just enable everything". Now I guess we need either to:

• Have different builds for ROBOTOLOGY_USES_GZ and ROBOTOLOGY_USES_GAZEBO, doubling the build matrix
• At the end of the build, add a step that enables ROBOTOLOGY_USES_GZ and disables ROBOTOLOGY_USES_GAZEBO (or the contrary)

Feel free to follow the path that make more sense to you, probably the second one is easier.

[xela-95]

@traversaro in

robotology-superbuild/doc/conda-forge.md

Lines 181 to 201 in 5737298

	### Compile the robotology-superbuild
	In a terminal in which you activate the `robsub` environment, you can compile.
	On **Linux** or on **macOS** with an Intel-based processor, run:
	~~~
	cd robotology-superbuild
	mkdir build
	cd build
	cmake ..
	cmake --build . --config Release
	~~~
	On **Windows**, run:
	~~~
	cd robotology-superbuild
	mkdir build
	cd build
	cmake -G"Visual Studio 16 2019" ..
	cmake --build . --config Release
	~~~

is not mentioned that when configuring the project the CMAKE_INSTALL_PREFIX variable should be set to CONDA_PREFIX. Is it on purpose?

[traversaro]

The superbuild is a bit special, as it does not have any install step. In its build (i.e. the invocation of make or ninja) step, it calls the install of all the subprojects. All the subprojects are installed in the build/install location, and this can't be easily changed. To consume projects compiled by the superbuild, one should source setup.sh script or similar, not install in $CONDA_PREFIX.

[xela-95]

The superbuild is a bit special, as it does not have any install step. In its build (i.e. the invocation of make or ninja) step, it calls the install of all the subprojects. All the subprojects are installed in the build/install location, and this can't be easily changed. To consume projects compiled by the superbuild, one should source setup.sh script or similar, not install in $CONDA_PREFIX.

Ok it's clear now thanks!

[xela-95]

@traversaro should I add the environment variable GZ_SIM_RESOURCE_PATH as it has been done for GAZEBO_MODEL_PATH to find the iCub and ErgoCub models for Gazebo Classic?

[traversaro]

@traversaro should I add the environment variable GZ_SIM_RESOURCE_PATH as it has been done for GAZEBO_MODEL_PATH to find the iCub and ErgoCub models for Gazebo Classic?

Yes. Eventually we will add gz-sim support there, so let's already do it so we can forget about this.

[traversaro]

Note that probably given all the problems related to co-installation of gz-sim and gazebo-classic we can skip the CI part for now.

[traversaro]

I left a bunch of comments, but the gist is the following: never use "Gazebo" without specification, it is going to be too confusing otherwise for users that called "Classic Gazebo" Gazebo for years.

[xela-95]

I left a bunch of comments, but the gist is the following: never use "Gazebo" without specification, it is going to be too confusing otherwise for users that called "Classic Gazebo" Gazebo for years.

Ok, what term we should use for new Gazebo? Modern Gazebo or gz-sim?

[xela-95]

I tested the usage of ergocub-software and gz-sim-yarp-plugins from the robotology-superbuild on Ubuntu 22.04 and WSL, both with conda-forgeand apt dependencies. Both worked as expected.

[traversaro]

Thanks, I think we can proceed with merging. Existing conda users may need to pay attention as now gazebo needs to be installed manually and is not installed by the long list of dependencies in the README, but I guess it should be easy to manage as a change. @xela-95 can I squash?

[xela-95]

Thanks, I think we can proceed with merging. Existing conda users may need to pay attention as now gazebo needs to be installed manually and is not installed by the long list of dependencies in the README, but I guess it should be easy to manage as a change. @xela-95 can I squash?

Yep exactly, now gazebo has to be installed manually also from conda, but I think this will not overcomplicate the workflow too much.

Sure, squeeze! 🧽