Interface composition revised

[mathias-luedtke]

As reported in PR2/pr2_mechanism#330 the changes introduced in #235 break hardware interfaces without default contructors.

This PR relaxes this by requiring the default constructor only for interfaces derived from hardware_interface::HardwareResourceManager.

In addition I have cleaned-up the code a little bit and got rid of some warnings.
This breaks the API of CheckIsResourceManager.

[bmagyar]

Sweet! 👍

[mathias-luedtke]

I don't know if CheckIsResourceManager::value is used by someone else, but the header is internal though.

[bmagyar]

The cmake suggests those files are not getting installed although they are available to other packages from within a source-based installation. I think it is safe to remove.

[mathias-luedtke]

The cmake suggests those files are not getting installed

They get installed! The others need them to be included.
I could just omit the las commit, but mark it as deprecated.
Update: If we keep them we won't get rid of the warnings.

In general the combined HW feature was not designed properly for reuse and maintenance :-/

[bmagyar]

Ah...I thought the internal folder wasn't within include/hardware_interface

What do you think about moving those header files into include/hardware_interface_internal so they can truly be internal-only. That'd partially patch up the reuse/maintenance aspect.
How much of it could we hide?

I wouldn't worry much about some hacky code breaking because those files are already marked internal and also pretty specific to this implementation.

[mathias-luedtke]

What do you think about moving those header files into include/hardware_interface_internal so they can truly be internal-only.

These are internal API files that are used (and implicitly exposed) by the public API.
But the internal prefix in the path should make clear that it is not meant to be public (=stable) and is subject to changes at any time.

We could move CheckIsResourceManager into the internal namespace to emphasize this.

[bmagyar]

The internal namespace is a good idea. Could you make that change please?

[mathias-luedtke]

done, this is an API break ;)

[bmagyar]

I approved, you merge ;)