In a super-build I’m switching sub-cmake-project’s CMAKE_PREFIX_PATH to different versions of my support packages.
However, when changing from one version to another, the cmake-configure-step is executed, but the find_package-calls inside are not invalidated - so when compiling, it still uses the previous package-version which points to the previous PREFIX_PATH-path.
Is this expected behavior?
Yes, it is expected.
find_package caches the found packages, so that subsequent calls just return immediatelly. It’s basically impossible to clean all those cached variables.
So if you want to use new value for CMAKE_PREFIX_PATH, you need to remove the cache file.
My real problem was a wrong dependency analysis of GNU Make. TL;DR: when changing the support-packages version (actually untarring an archive) I have to touch recursively all files (tar -m) so that their modification times change to untar-time.
This makes all dependencies work correctly, with make.
ExternalProject learned how to deal with that using DOWNLOAD_EXTRACT_TIMESTAMP OFF if you want to use that to download (and extract) things for you.
Also note that one wants to continue using cached values in case, say, a new version is installed somewhere in a search path. Otherwise it becomes very difficult to “stick” to something not found first in the search path because it is hard to know if the results come from actually wanting what has already been found or whether something “new” should be preferred.