[question] Interactions between cmake cache and find_package for config.cmake files provided by the package itself.

[huysentr]

What is your question?

Hi, I have a question regarding an issue have been running into (using conan 1.62 atm).
When I use find_package() in my CMake code I can run into two possibilities.

• Either I use the config.cmake generated by CMakeDeps generator, this will be fresh everytime I conan install a new version of a package and will always point to the correct package folder.
• However if I decide to use the config.cmake provided by the package developer themselves. The find_package() will now point to the package in the conan cache. This location is saved in the CMake cache of my project, If I do not clear my CMake cache I will run into issues installing a newer version.

Note that our projects are very large, we have scripts to reset cmake cache variables, but it requires some maintenance work. (We disregard adding versions to the find_package, we rely on our conan requirements to manage this). Are we missing an option or feature that could help us with this problem?

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[jcar87]

However if I decide to use the config.cmake provided by the package developer themselves. The find_package() will now point to the package in the conan cache. This location is saved in the CMake cache of my project, If I do not clear my CMake cache I will run into issues installing a newer version.

This is correct - my understanding is that once CMake caches the results of a find_package, the safest way to reset it to point to a different location is to clear again. It's not only the location of the previously-found -config.cmake file that may be cached, other variables of artibrary names may be created (including for secondary dependencies with find_dependency) so it's not a given.

Note that our projects are very large, we have scripts to reset cmake cache variables, but it requires some maintenance work.

This sounds like a good idea if you can reliably detect that find_package need to be rerun because of changes in the paths in the conan dependencies. That is tricky itself, but also, as you mention, even when you detect this situation you need to selectively reset all relevant environment variables - the problem is that sometimes those cache variables are arbitrary with non-predictable names.

Are we missing an option or feature that could help us with this problem?

I don't think so! If your projects are so large that a full cmake re-configure is impractical, I think you are doing the right thing. The only think I can think of is ... implement your own dependency provider (see CMake docs), to intercept all calls to find_package - and if you detect the situation that something needs to be run "from fresh" (ignoring previous cache entries), you can probably control it from here (by conditionally unsetting those cache variables). Problem is, you need to know the name of those variables.

I think this is generally a CMake limitation that exists outside of Conan - once a find_package leaves a trail in the CMake cache, even modifying the cache variables themselves is not always safe (AFAIK).

[huysentr]

So can I request a possibility to copy the existing config files to the same directory where conan generates its config files? That would negate the issue completely. Such that the find_package() for any package will all point to the conan build directory.

[memsharded]

So can I request a possibility to copy the existing config files to the same directory where conan generates its config files? That would negate the issue completely. Such that the find_package() for any package will all point to the conan build directory.

It is not fully clear what you mean, do you mean the xxx-config.cmake packages that are inside the packages, to copy them to another location, like the folder where Conan is generating its own config.cmake files? I am afraid it wouldn't work, because those files cannot be separated from the package, they will most likely contain relative paths, and will break if moved.