# Should a change to CMAKE\_PREFIX\_PATH invalidate find\_package()

**URL:** <https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249>\
**Category:** Code\
**Created:** [October 16, 2025, 8:04am UTC](https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249 "2025-10-16T08:04:32Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![pboettch](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pboettch/32/216_2.png) [@pboettch](https://discourse.cmake.org/u/pboettch)\
**Post date:** [October 16, 2025, 8:04am UTC](https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249/1 "2025-10-16T08:04:32Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![fenrir](https://discourse.cmake.org/user_avatar/discourse.cmake.org/fenrir/32/734_2.png) [@fenrir](https://discourse.cmake.org/u/fenrir)\
**Post date:** [October 16, 2025, 9:25am UTC](https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249/2 "2025-10-16T09:25:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pboettch](https://discourse.cmake.org/user_avatar/discourse.cmake.org/pboettch/32/216_2.png) [@pboettch](https://discourse.cmake.org/u/pboettch)\
**Post date:** [October 16, 2025, 2:19pm UTC](https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249/3 "2025-10-16T14:19:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [October 19, 2025, 1:31am UTC](https://discourse.cmake.org/t/should-a-change-to-cmake-prefix-path-invalidate-find-package/15249/4 "2025-10-19T01:31:24Z")

</div>

`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.