FindUUID: Always define UUID::UUID on Apple platforms

[traversaro]

On Apple platforms, the headers of libuuid and its symbols are provided by the OS SDK, so no further linking is necessary.

Fix #127

Signed-off-by: Silvio Traversaro silvio.traversaro@iit.it

[scpeters]

diff without whitespace: https://github.com/ignitionrobotics/ign-cmake/pull/128/files?w=1

[scpeters]

this looks reasonable to me; I'd just like to test it with a larger set of packages before approving

[traversaro]

this looks reasonable to me; I'd just like to test it with a larger set of packages before approving

Thanks, I don't have currently a macOS box to test, so any additional test is welcome.

[traversaro]

I actually was able to propagate the change in conda and test it in https://github.com/robotology/robotology-superbuild/pull/513/https://github.com/robotology/robotology-superbuild/pull/513/checks?check_run_id=1414508924, and I found another problem: the target should only be defined if no target with the same name is already defined, otherwise if you call twice find_package(UUID) as it happes when you call find_package(gazebo) thanks to dependencies, you will get the error:

2020-11-17T20:31:22.6139260Z CMake Error at /usr/local/miniconda/envs/test/share/cmake/ignition-cmake2/cmake2/FindUUID.cmake:61 (add_library):
2020-11-17T20:31:22.6140410Z   add_library cannot create imported target "UUID::UUID" because another
2020-11-17T20:31:22.6141100Z   target with the same name already exists.

I fixed the problem in the latest version of the PR.

[scpeters]

sorry for the delayed review; this looks good. I suppose we can stop depending on the ossp-uuid formula in osrf/homebrew-simulation as well. I'll open a ticket for that