Add ign plugin --info to print plugin info

[scpeters]

This adds an ign plugin --info command to the loader component that attempts to load a specified shared library and print information about the plugins and interfaces in that file. My motivation for this is to support development of ignition-physics Implementation plugins, though it is useful for other plugins as well. I've added libignition-tools-dev to the packages.apt in this PR and to the homebrew formula in osrf/homebrew-simulation#1213.

$ ign plugin --help
Print information about plugins.

  ign plugin [options]

Options:

  -i [ --info ]              Get info about a plugin.
                             Requires the -p option.

  -p [ --plugin ] arg        Name of a plugin.
                             Required with -i.

  -v [ --verbose ]           Print verbose info.

  -h [ --help ]              Print this help message.
                                                    
  --force-version <VERSION>  Use a specific library version.
                                                    
  --versions                 Show the available versions.

For example, given a path to the DummyPlugins shared library used in unit tests for the loader component, ign plugin --info --plugin lib/libIGNDummyPlugins.dylib generates the following output.

$ ign plugin --info --plugin lib/libIGNDummyPlugins.dylib
Loading plugin library file [lib/libIGNDummyPlugins.dylib]
* Found 3 plugins in library file:
  - test::util::DummyMultiPlugin
  - test::util::DummyNoAliasPlugin
  - test::util::DummySinglePlugin
* Found 7 interfaces in library file:
  - test::util::DummyNameBase
  - test::util::DummyGetObjectBase
  - test::util::DummyIntBase
  - test::util::DummyGetPluginInstancePtr
  - test::util::DummyDoubleBase
  - test::util::DummySetterBase
  - ignition::plugin::EnablePluginFromThis

More verbose output from the Loader::PrettyStr() function can be printed with the --verbose flag.

$ ign plugin --info --plugin lib/libIGNDummyPlugins.dylib --verbose
Loading plugin library file [lib/libIGNDummyPlugins.dylib]
Loader State
	Known Interfaces: 7
		test::util::DummyNameBase
		test::util::DummyGetObjectBase
		test::util::DummyIntBase
		test::util::DummyGetPluginInstancePtr
		test::util::DummyDoubleBase
		test::util::DummySetterBase
		ignition::plugin::EnablePluginFromThis
	Known Plugins: 3
		[test::util::DummyMultiPlugin]
			has 3 aliases:
				[Bar]
				[Baz]
				[Foo]
			implements 7 interfaces:
				ignition::plugin::EnablePluginFromThis
				test::util::DummyDoubleBase
				test::util::DummyGetObjectBase
				test::util::DummyGetPluginInstancePtr
				test::util::DummyIntBase
				test::util::DummyNameBase
				test::util::DummySetterBase
		[test::util::DummyNoAliasPlugin]
			has no aliases
			implements 1 interface:
				test::util::DummyNameBase
		[test::util::DummySinglePlugin]
			has 3 aliases:
				[Alternative name]
				[Bar]
				[Baz]
			implements 1 interface:
				test::util::DummyNameBase
	There are 2 aliases with a name collision:
		[Bar] collides between:
			[test::util::DummyMultiPlugin]
			[test::util::DummySinglePlugin]
		[Baz] collides between:
			[test::util::DummyMultiPlugin]
			[test::util::DummySinglePlugin]

[chapulina]

Did you consider adding a new component for the command line tools, so that users of the plugin loader aren't required to bring ign-tools? The Ruby dependency is often undesired.

[scpeters]

Did you consider adding a new component for the command line tools, so that users of the plugin loader aren't required to bring ign-tools? The Ruby dependency is often undesired.

From a build perspective, ign-tools isn't a required dependency; it's merely an optional dependency for tests. (For comparison, ruby is a required build dependency for libsdformat, since it is used to generate the schema files). With this PR, we will be configuring and installing some extra files, and one needs to install ignition-tools in order to use them

The only impact it has on the loader is adding one symbol to the loader component library, but that seems small to me compared to the extra effort of adding another component. I think we could create a separate debian package in the metadata to install the ign files without modifying the cmake code any further here

[chapulina]

I think we could create a separate debian package in the metadata to install the ign files without modifying the cmake code any further here

Ok, I think this could be a good separation. So just to clarify, this will be the situation, right?

• Installing libignition-plugin(-dev) won't install ignition-tools
• ign_find_package(ignition-plugin1 REQUIRED COMPONENTS loader) won't fail if ignition-tools isn't installed

[chapulina]

Works for me! I tried it with plugins from several libraries.

[chapulina]

Should we open a ticket to track command line support on Windows?

[scpeters]

I think gazebosim/gz-tools#7 will help with windows support eventually

[chapulina]

@scpeters , is this PR pending anything else?

[scpeters]

@scpeters , is this PR pending anything else?

hm...I think I was waiting to see how gazebosim/gz-transport#216 turned out, but I guess we would need ign-utils to follow that pattern

I think this could be fine as is since I don't think we would add ign-utils as a dependency on ign-plugin1

[chapulina]

Yeah we could do the current approach on ign-plugin1 and update it to use ign-utils on ign-plugin2 if that's desired.

[chapulina]

Oops, this broke downstream CI:

https://build.osrfoundation.org/job/ign_gui-pr-win/625/console

CMake Error in loader/src/cmd/CMakeLists.txt:
  Evaluation file to be written multiple times with different content.  This
  is generally caused by the content evaluating the configuration type,
  language, or location of object files:

   D:/Jenkins/workspace/ign_gui-pr-win/ws/build/ignition-plugin1/test/lib/ruby/ignition/cmdplugin1.rb

[scpeters]

Oops, this broke downstream CI:

I just noticed this. I'll revert unless I find a quick fix