Hi @hekrdla - thank you for raising this issue.

Unfortunately there isn't a uniform convention with regards to these variables - so no matter which solution we go for, some packages may end up with variables names that do not patch pre-existing conventions.

Conan tries to follow the conventions specified in the CMake documentation here: https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names

which mentions the following:

Note that all variables start with Xxx_, which (unless otherwise noted) must match exactly the name of the FindXxx.cmake file, including upper/lowercase. This prefix on the variable names ensures that they do not conflict with variables of other Find modules. The same pattern should also be followed for any macros, functions and imported targets defined by the Find module.

This convention is not always followed by library maintainers, and I suspect it may not have been uniformly followed by CMake-provided find modules.

CMake guidelines also overwhelmingly recommend the use of imported targets - so beyond the fact that the variables don't follow convention, it is also unfortunate that they are used at all.

self.cpp_info.set_property("cmake_result_variables_name", "OPENJPEG")

I think this is a good idea and something for us to consider - I would probably opt for a different property name, such as cmake_legacy_variable_prefix, where you could have:

self.cpp_info.set_property("cmake_file_name", "OpenJPEG")
self.cpp_info.set_property("cmake_legacy_variable_prefix", "OPENJPEG")

To achieve the desired result.

I don't think more complexity is needed. For example:

• FindPythonLibs is deprecated in favour of FindPython, which has been available since version 3.12
• <PackageName>_LIBRARY are mentioned as internal to modules, and not intended to be used externally: https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names - where these usage occurs, I would greatly encourage to submit an issue report to the library maintainers and point them in the direction of using the publicly facing variable names, or better yet, targets

Please also note that sometimes the same package is used differently by consumers (different variable names, internal find modules), and that that the generator can be tweaked on the consumer side (not just in the package_info()), precisely in order to avoid patches (Which we all agree are cumbersome to maintain):
https://docs.conan.io/2/reference/tools/cmake/cmakedeps.html#overwrite-properties-from-the-consumer-side-using-cmakedeps-set-property

@jcar87 I agree with you that all of that should be deprecated since CMake 3.0.0 2014 in favor of targets. But here we are in 2023 and still deal with it :-(

I know that this will not cover everything, but this should cover a lot. And if not, there is still possibility to use conan-official-{name}-variables.cmake like openssl do.
This should be preferred way, instead of patching usage (if usage expect official naming). Because as I see, these patches miss a lot and even if they cover everything they will require a lot more maintenance in feature.

I don't check all CMake built-in finders, but what I see they respect these inconsistencies and deprecated thinks, because they should. Even <PackageName>_LIBRARY or VERISON_... related variables are there, because if they don't, these finders will not work as someone may expect.

edit: sad example how <PackageName>_LIBRARY is not intended to be used externally: https://github.com/conan-io/conan-center-index/blob/master/recipes/leptonica/all/patches/fix-find-modules-variables.patch

I agree that FindPythonLibs is weird one and maybe only one.

List of variables I propose are most common, as I know. And my premise is that defining variable that not exists in original Config.cmake is no issue, because nobody should expect it, so it will not used. But not defining variable that should exists may be problem, because it may mean different behavior instead of error.

I hope something like that will be added in whatever way.

I've submitted one month ago a fix for openjpeg recipe (conan-io/conan-center-index#19230), providing these variables in file generated by CMakeDeps, and fixing opencv issue when jpeg2000 backend is openjpeg (issue reported in conan-io/conan-center-index#19219). It's just waiting for one team review.

And FYI, regarding extra CMake variables, there was #7691, but it has been closed since it was referring to legacy cmake_find_package* generators.