[bug] CMake.patch_config_paths() should use cpp_info.name

I am using CMake.patch_config_paths() in some of my recipes to make it easier to share packages on a Conan server at work, but it seems that it wasn’t updated to take into account the new cpp_info.name feature.

Case in point I have a recipe to build VTK with CMake and I call patch_config_paths(), which introduces the following variable:

set(vtktiff_LIBRARIES "${CONAN_LIBTIFF_ROOT}/lib/libtiff.so")

However some of my recipes consume VTK with the cmake generator, and the following variable is defined instead in conanbuildinfo.cmake: CONAN_TIFF_ROOT.

It looks like the the cmake generator uses the cpp_info.name to generate the variable names in conanbuildinfo.cmake but the function patch_config_paths() from the CMake build helper still uses the Conan dependency’s name in uppercase.

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 18.04
• Compiler+version: g++ 7.4
• Conan version: 1.19.3
• Python version: 2.7.15+

Logs

The only relevant logs that helped me to get there were the following CMake warnings (included here in case someone looks for helps and ends up here by looking up the error):

CMake Warning at source_subfolder/modules/VTK/tests/CMakeLists.txt:15 (add_executable):
  Cannot generate a safe runtime search path for target vtkStatismoTest
  because files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libtiff.so] in /lib may be hidden by files in:
      ~/.conan/data/libtiff/4.0.9/_/_/package/6d4315d6fa76c4ef3a26fbf347fda7039440232c/lib

  Some of these libraries may not be found correctly.

[memsharded]

Yes, it is impossible to use the cpp_info.name there, because it would be a chicken-and-egg problem. The package_info() method needs the package to be built (there are things like tools.collect_libs(), that will scan the folders to define the library names).

Surprising thing here, is that cpp_info.name is used to account for the default or expected name in typical cmake-generated scripts. And the thing that patch_config_paths is patching are cmake-generated scripts. So in general, I would expect that those scripts already contain the cmake default name, no need to change there anything, and cpp_info.name would be use to make the information in conan generated files like conanbuildinfo.cmake to match that cmake default name.

[Morwenn]

Good catch, I didn’t think about that.

In my case it wouldn’t really solve the problem though: my ITK recipe generates the name CONAN_LIBTIFF_ROOT when I call patch_config_paths(), but I shouldn’t know or care that ITK reexports names linked to libtiff. Basically I have the issue with files generated by ITK yet the name which is faulty isn’t the ITK one but the TIFF one, so name= wouldn’t solve my issue here since it could only fix the ITK name.

I guess that I will try to circumvent the issue by not having ITK export its own config files at all, and thus not using patch_config_files() (like the packages on CCI). I can try to rely on cmake_find_package_multi in the consumer packages, but I can’t tell for now whether everything will still work.