[feature] `CONAN_RUNTIME_LIB_DIRS` for CMakeDeps

[FeignClaims]

What is your suggestion?

Hi! I'm adding a feature to automatically install conan runtimes in a cmake library aminya/project_options#279. Since the usage of conan is optional, the repo chooses to use cmake-conan. However, CONAN_RUNTIME_LIB_DIRS is set by CMakeToolchain while cmake-conan could only supports CMakeDeps, so I couldn't install runtimes when using cmake-conan.

I would like to have some way to collect CONAN_RUNTIME_LIB_DIRS when only CMakeDeps is specified.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Thanks for your suggestion @FeignClaims

There are some challenges in defining these kind of variables in CMakeDeps generators, because they are very focused on the find_package() and target interfaces. But I am adding this to the next 2.9 for having a look to see if something can be done.

[jcar87]

We can probably define this variable in cmake-conan, I think it would make sense to have it. @memsharded - the implementation would actually be very similar to the solution for https://github.com/conan-io/cmake-conan/issues/669

[memsharded]

I am adding this variable to the new conan_cmakedeps_paths.cmake generated by the new CMakeDeps in https://github.com/conan-io/conan/pull/16964 (which will close this ticket, then it needs to be completed in cmake-conan)

[memsharded]

We are releasing in Conan 2.9 a completely new CMakeDeps generator in https://github.com/conan-io/conan/pull/16964 that has closed this ticket, with many pending features and fixes:

• Allow defining cpp_info.default_components and using that information to generate CMake targets by default for packages
• Allow defining cpp_info.exe to model executable imported targed generation
• Creating always actual SHARED/STATIC/INTERFACE imported targets, with their IMPORTED_LOCATION, the IMPORTED_IMPLIB, the IMPORTED_CONFIGURATIONS
• This solves issues with try_compile and other CMake source-compiling checks
• No artificial library or package targets
• Allow using the package languages attribute or a new cpp_info.languages information to define IMPORTED_LINK_INTERFACE_LANGUAGES
• Define config files for executable targets for the "build" context automatically, without any special configuration
• Use the correct CONFIGURATION from the package instead of the consumer one
• Generate a new conan_cmakedeps_paths.cmake file, that can be used for integrations that cannot use a CMakeToolchain, like cmake-conan, this will contain the CONAN_RUNTIME_LIB_DIRS variable
• Allow using executable targets from the host context if not cross-building (and not tool-requires that would prioritize those executable targets)

Current known pending functionality (to be added soon):

• Not managing Apple frameworks
• Not generating find modules, only CMake Config files

The new CMakeDeps generator is intended for testing and validation only, being a transparent replacement of the old one, so it is behind a new conf. To use it, use the -c tools.cmake.cmakedeps:new=will_break_next, and that will use the new generator instead of the old one. Note the will_break_next value means exactly that, that value will change in next release to force a break, so no one can depend on this generator in production yet.

Your feedback is very important

As this is a major change, we will only remove the conf gate when we get confirmation from users that it works and solve the issues. Please try the new generator for your project, and let us know if it works. If it doesn't, please re-open this ticket and let us know what failed. Thanks very much!