Improvements and cleanup of signals and ports

[diegoferigo]

Since the time of wb-toolbox there was some confusion between properties and information assigned to signals and ports. Sometimes things related to one were used on the other.

This PR:

• Introduces a new core::Port class that collects most of the information about ports, and removes it from core::Signal and core::BlockInformation.
• Removes the size optional argument when asking a Signal object from BlockInformation implementations. This should never be the case since this information should be stored inside the BlockInformation object in the configuration phase and the blocks should not have the power of asking a signal with a size that might mismatch with the right one.
• Cleans buffer initialization of the core::Signal class. Now the size of the buffer is specified when the buffer pointer is stored. This should provide more robust APIs since there won't be anymore the need to remember to call Signal::setWidth in order to have a valid object.

[traversaro]

Ack.

One thing to note (even if not directly related to this PR) is that there is no documentation on where to install the blockfactory plugins in the install prefix. As a superbuild mantainer, I would like that all the projects in the superbuild just install their blockfactory plugins in the same install directory, so I just need to define BLOCKFACTORY_PLUGIN_PATH once.

Additionally, w.r.t. to debian packaging, it would be good if the default installation prefix was in the search path even without the need to define BLOCKFACTORY_PLUGIN_PATH, so that if in the future we have deb package of BlockFactory + WB-Toolbox, they will just work out of the box without the need to define any env variable.

[diegoferigo]

One thing to note (even if not directly related to this PR) is that there is no documentation on where to install the blockfactory plugins in the install prefix.

I tried to handle it with the install_blockfactory_plugin CMake function:

blockfactory/cmake/BlockFactoryPlugin.cmake

Lines 93 to 100 in 39b3d44

	install(
	TARGETS ${plugin_name}
	EXPORT ${plugin_name}Export
	RUNTIME DESTINATION "${CMAKE_INSTALL_BINDIR}/blockfactory" # Location of the .dll
	ARCHIVE DESTINATION "${CMAKE_INSTALL_LIBDIR}/blockfactory" # Location of the .lib
	LIBRARY DESTINATION "${CMAKE_INSTALL_LIBDIR}/blockfactory" # Location of the .so / .dylib
	PUBLIC_HEADER DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/${plugin_name}/Block")
	endfunction()

And there is a message displayed when configuring the project (in addition to the website):

blockfactory/cmake/BlockFactoryPlugin.cmake

Lines 85 to 91 in 39b3d44

	if(WIN32)
	message(STATUS "Remember to add \"${CMAKE_INSTALL_PREFIX}\${CMAKE_INSTALL_BINDIR}\blockfactory\""
	" to BLOCKFACTORY_PLUGIN_PATH environment variable")
	else()
	message(STATUS "Remember to add \"${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}/blockfactory\""
	" to BLOCKFACTORY_PLUGIN_PATH environment variable")
	endif()

Additionally, w.r.t. to debian packaging, it would be good if the default installation prefix was in the search path even without the need to define BLOCKFACTORY_PLUGIN_PATH, so that if in the future we have deb package of BlockFactory + WB-Toolbox, they will just work out of the box without the need to define any env variable.

This is more complicated. If we install plugins in one of the default linker folder, we get the same problems due to LD_LIBRARY_PATH we recently discussed in robotology/ycm-cmake-modules#199 and robotology/robotology-superbuild#97.

[diegoferigo]

@traversaro I would keep this discussion going in a new issue, feel free to open it. In the meantime, I proceed merging this PR.

[traversaro]

I tried to handle it with the install_blockfactory_plugin CMake function:

You are right, sorry for missing it!

[traversaro]

I would keep this discussion going in a new issue, feel free to open it. In the meantime, I proceed merging this PR.

Ok, new issue open in #34 .

[diegoferigo]

Merged, thanks!