[bug] find frameworks path is cached in cmake and not invalidated when dependency updates

[technic]

Describe the bug

this code from cmakedeps_macros.cmake has nasty bug

macro(conan_find_apple_frameworks FRAMEWORKS_FOUND FRAMEWORKS FRAMEWORKS_DIRS)
    if(APPLE)
        foreach(_FRAMEWORK ${FRAMEWORKS})
            # https://cmake.org/pipermail/cmake-developers/2017-August/030199.html
            find_library(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND NAMES ${_FRAMEWORK} PATHS ${FRAMEWORKS_DIRS} CMAKE_FIND_ROOT_PATH_BOTH)
            if(CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND)
                list(APPEND ${FRAMEWORKS_FOUND} ${CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND})
                message(VERBOSE "Framework found! ${FRAMEWORKS_FOUND}")
            else()
                message(FATAL_ERROR "Framework library ${_FRAMEWORK} not found in paths: ${FRAMEWORKS_DIRS}")
            endif()
        endforeach()
    endif()
endmacro()

It caches CONAN_FRAMEWORK_${_FRAMEWORK}_FOUND variable and after conanfile is updated with the new version cmake still uses old cached framework.

This is CMakeDeps generator, conan 1.64. I suppose conan v2 has similar issue, but I didn't check

How to reproduce it

No response

[memsharded]

Hi @technic

Thanks for your report.

In some situations it is true that the CMake caching will interfere with dependencies changes. In general, when changing things outside of the current project, like Conan dependencies, we would recommend to invalidate the CMake cache when possible to avoid potential caching issue.

In any case, we are moving to a different model, based on the CPS standardization effort (that we are participating in), and we are implementing a new CMakeDeps generator in #16964. This will not have the cmakedeps_macros.cmake file or the find_frameworks() at all, so that will solve the issue already.

[technic]

I think this can be fixed, if I look at how conan_package_library_targets is implemented there is unset(CONAN_FOUND_LIBRARY CACHE) call which removes the location from the cache. And there is no per library variable for it. Why do we have ${_FRAMEWORK} part of the variable?

even better is to do such search in conan during generate() and provide full path to cmake instead of doing find_library calls. This will be faster when doing cmake reconfigure.
Also this will probably make creating CONAN_LIB:: targets not needed. I want to do install(IMPORTED_RUNTIME_ARTIFACTS) in cmake but I cant do it for normal target like zlib::zlib because it is a proxy target to CONANLIB::bla-bla target. This is inconvenient.

[memsharded]

I think this can be fixed, if I look at how conan_package_library_targets is implemented there is unset(CONAN_FOUND_LIBRARY CACHE) call which removes the location from the cache. And there is no per library variable for it. Why do we have ${_FRAMEWORK} part of the variable?

I see. If you think it is worth to try to unset() or something like that to avoid the issue, please try to contribute a Pull Request.

even better is to do such search in conan during generate() and provide full path to cmake instead of doing find_library calls. This will be faster when doing cmake reconfigure.

This is basically what the new CMakeDeps is doing, together with an augmented new model in cpp_info that includes information like cpp_info.location.
Also the full generation of targets is different in the new CMakeDeps, no CONAN_LIB targets is generated. Please have a look to the PR #16964, it will also be made available in Conan 2.9 under a new conf to activate it (exclusively for testing, not for production).

[memsharded]

I am re-opening this, this was not really solved yet by #16964