[package] util-linux-libuuid uses wrong cmake target

[samuel-emrys]

Description

In the following lines, the util-linux-libuuid recipe sets the cmake target to be LibUUID::LibUUID with a filename of LibUUID-config.cmake:

conan-center-index/recipes/util-linux-libuuid/all/conanfile.py

Lines 112 to 113 in 61c4f78

	self.cpp_info.set_property("cmake_target_name", "LibUUID::LibUUID")
	self.cpp_info.set_property("cmake_file_name", "LibUUID")

This was based on the internal practice that Kitware has for their internal libuuid cmake module, however this is not public and a number of packages (czmq, cppcommon) seem to assume a libuuid::libuuid target. These change should be reverted such that these packages can utilise util-linux-libuuid without a requirement to be patched.

Package and Environment Details

N/A

Conan profile

N/A

Steps to reproduce

N/A

Logs

Click to expand log

Put your log output here

[jcar87]

I've made a comment on the PR: #18559

I think there is an argument that libuuid::libuuid (all lower case) is internal to Conan Center and unlikely to be referenced outside of Conan Center - while LibUUID::LibUUID is part of a public CMake find module, and thus overwhelmingly more likely to be found out in the wild.
You can see for instance: https://github.com/search?q=libuuid%3A%3Alibuuid+language%3Acmake&type=code , where LibUUID::LibUUID is more common, and libuuid::libuuid is only used by project-private find modules.

Given that there are only 10 recipes that need to be updated to use util-linux-libuuid (#19084), I would probably ensure those use the LibUUID Cmake find_package / target names instead - in some cases this means we can remove patches and workarounds altogether.

[samuel-emrys]

Good point. That's a good way to identify commonality. In contrast, looks like uuid::uuid or UUID::UUID is more common than that again: https://github.com/search?q=uuid%3A%3Auuid+language%3Acmake&type=code

[jcar87]

looks like uuid::uuid or UUID::UUID is more common than that again: https://github.com/search?q=uuid%3A%3Auuid+language%3Acmake&type=code

This may indeed be the case, however, I can see that in those instances, project-private find modules are used. The only find modules that we consider authoritative are the CMake built-in. Each may have different conventions. For specific cases where a project uses a custom name, we have the ability to tweak the target name in the generate() method.