[question] Fair Play

[Minimonium]

It'd be nice to explicitly state in contribution guidelines such rules that would allow Conan repository to not be against the world, but play nicely with it.

• After the Components feature comes in, each contribution should specify names in the cppinfo in accordance with the upstream project's build scripts. Would allow users of these libraries in the native build system to plug&play Conan.

• Extending [question] What's the policy on name collisions.  #21, we should check if there same packages in the Vcpkg, another fairly popular dependency manager, and name our projects the same if so (though I understand that there could be moments when we can't).

[danimtb]

I think the common sense in naming is the best approach and is the summary of my answer in #23

I understand the issue but it is not a concern right now as the cpp_info.name is still not there.

[gocarlos]

Naming issues are actually the most problematic usage of conan in our case: we build with conan for x86 (native development) and within yocto for ARM with upstream cmake scripts (for production due to sw clearing, reproducibility etc.) , often there is a name mismatch from the exported targets from conan...

We are at some places using cmake generator expressions to handle both cases with is suboptimal...

[danimtb]

@gocarlos the issue should be mitigated by this PR in Conan conan-io/conan#5598 where you can actually declare the "cmake name" of a library inside its recipe.

Of course, I understand naming is important and now with this repository, we can transparently discuss and fix this kind of stuff 😄

[gocarlos]

@danimtb after conan-io/conan#5598 one could start using the target names for the cmake test packages as already done for zlib (https://github.com/conan-io/conan-center-index/blob/master/recipes/zlib/1.2.11/test_package/CMakeLists.txt) test package instead of using ${CONAN_LIBS}

[danimtb]

Yes, sure. That is the final goal of the feature proposed there. Hopefully, we will have it in the next Conan release

[danimtb]

self.cpp_info.name was released in Conan 1.19. As recipes in conan-center-index run with the latest Conan, this information can be now used. Thanks

[gocarlos]

is there already a way to export two targets to cmake with self.ccp_info.name?

e.g. my CMakeLists.txt creates two libs: mylib::part_one and mylib::part_two, tough in the generated Findmylib.cmake I only see mylib::mylib

[Minimonium]

This would require the conan-io/conan#5408

[Croydon]

I think this can be closed. We have proper CMake targets and always try to follow upstream naming conventions.

And regarding naming conflicts of packages, we have a documented policy for that and there don't seem to be problems in practice so far with it.