Decoupling the server from the client libraries

[j-rivero]

While working on gazebo-release/gz-sim8-release#8 I found some difficulties into splitting the packaging from client/server in gz-sim. Note that we mainly want to split the GUI libraries (specially those that needs Qt) into a separate package.

Reviewing the situation: there are two libraries that links against Qt:

/usr/lib/x86_64-linux-gnu/libgz-sim8-gui.so.8.6.0
	libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x000074453e000000)
	libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 (0x000074453da00000)
	libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 (0x000074453d400000)
	libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x000074453cc00000)
	libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x000074453c600000)
	libQt5QmlModels.so.5 => /lib/x86_64-linux-gnu/libQt5QmlModels.so.5 (0x000074453d892000)
	libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x000074453b454000)
...
/usr/lib/x86_64-linux-gnu/libgz-sim8-gz.so.8.6.0
	libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x0000792777000000)
	libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x0000792776000000)
	libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 (0x0000792775a00000)
	libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 (0x0000792775400000)
	libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x0000792774c00000)
	libQt5QmlModels.so.5 => /lib/x86_64-linux-gnu/libQt5QmlModels.so.5 (0x0000792776aba000)
	libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x0000792773c54000)

While the gz-sim8-gui is expected to use the Qt symbols and we can package it in a separate GUI package the
libgz-sim8-gz library is probably use by the calls to server and client at the same time.

If I'm not wrong the related code is:

gz-sim/src/CMakeLists.txt

Lines 212 to 229 in 4c2797d

	target_link_libraries(${PROJECT_LIBRARY_TARGET_NAME}
	PUBLIC
	gz-math${GZ_MATH_VER}
	gz-plugin${GZ_PLUGIN_VER}::core
	gz-common${GZ_COMMON_VER}::gz-common${GZ_COMMON_VER}
	gz-common${GZ_COMMON_VER}::graphics
	gz-common${GZ_COMMON_VER}::profiler
	gz-fuel_tools${GZ_FUEL_TOOLS_VER}::gz-fuel_tools${GZ_FUEL_TOOLS_VER}
	gz-gui${GZ_GUI_VER}::gz-gui${GZ_GUI_VER}
	gz-physics${GZ_PHYSICS_VER}::core
	gz-rendering${GZ_RENDERING_VER}::core
	gz-transport${GZ_TRANSPORT_VER}::gz-transport${GZ_TRANSPORT_VER}
	gz-transport${GZ_TRANSPORT_VER}::parameters
	sdformat${SDF_VER}::sdformat${SDF_VER}
	protobuf::libprotobuf
	PRIVATE
	gz-plugin${GZ_PLUGIN_VER}::loader
	)

Question to answer is: is there a real need to link the gz CLI to these GUI libraries or we can remove the linking? If there is a real need, why we can not run the gz sim -s without the Qt libraries?

[azeey]

I think there are two issues:

• There's a runGui command inside gz.cc that launches the GUI (

  gz-sim/src/gz.cc

  Line 439 in 1739bdb

  extern "C" int runGui(const char *_guiConfig, const char *_file, int _waitGui,

  ). This brings in all the Qt libraries.
• the CLI target is linked against the core library (

  gz-sim/src/CMakeLists.txt

  Line 183 in 1739bdb

  ${PROJECT_LIBRARY_TARGET_NAME}

  ), which itself is linked against gz-gui (

  gz-sim/src/CMakeLists.txt

  Line 220 in 1739bdb

  gz-gui${GZ_GUI_VER}::gz-gui${GZ_GUI_VER}

  )

I think the best option is to accelerate gazebosim/gz-tools#7, which will give us the option to have separate binaries for the server and the GUI. @sauk2 is already working on this, so it'd be great if we focus our efforts on supporting him.