# Best practice setting package paths for \`find\_dependency\` in \`-config.make\` files?
**URL:** https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408
**Category:** Code
**Created:** [December 16, 2025, 6:17pm UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408 "2025-12-16T18:17:30Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Peter\_Hill](https://discourse.cmake.org/u/Peter_Hill)
#### Post date: [December 16, 2025, 6:17pm UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408/1 "2025-12-16T18:17:30Z")
We have a library which has several dependencies: some optional, some required, some bundled. Our package config file looks something like:
```cmake
include(CMakeFindDependencyMacro)
find_dependency(foo)
if (@PROJECT_HAS_BAR@)
find_dependency(bar)
endif()
```
`foo` is required, so we give an option `DOWNLOAD_FOO` to call `FetchContent`, but users may use their own built `foo` instead.
When building our library, users might configure it with `-DDOWNLOAD_FOO=on -DUSE_BAR=on -Dbar_ROOT=/path/to/bar`.
Now, when consuming our library, users have to tell CMake where to find `foo` and `bar`, so we actually also have the following in our `-config.cmake`:
```cmake
if (EXISTS "@foo_ROOT@")
set(foo_ROOT "@foo_ROOT@")
elseif (EXISTS "@foo_BINARY_DIR@")
list(APPEND CMAKE_PREFIX_PATH "@foo_BINARY_DIR@")
endif()
if (EXISTS "@bar_ROOT@")
set(bar_ROOT "@bar_ROOT@")
endif()
```
This way, users don’t need to also supply `-Dfoo_ROOT=/path/to/root -Dbar_ROOT=/path/to/root` to the downstream project as well. In particular, the correct path for `foo_ROOT` is not necessarily obvious as it may be buried inside our library’s build directory.
This is of course quite fragile, and has some problems, but I haven’t been able to find how this is best handled. Is there a better way? Should our downstream users just be expected to supply all the same paths and arguments to both projects? That’s not going to make us very popular.
---
### Author:  [@retif](https://discourse.cmake.org/u/retif)
#### Post date: [December 18, 2025, 1:04pm UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408/2 "2025-12-18T13:04:07Z")
> when consuming our library, users have to tell CMake where to find `foo` and `bar`
From my experience, that is how things should work, so this is to be expected and should not come as a surprise to users. Having `find_dependency()` calls in one’s package CMake config is sufficient.
I certainly would not try to “guess” the paths to dependencies for users, I don’t see how that would work, unless users are somehow operating on that same host with all the same paths.
---
### Author:  [@Andrej730](https://discourse.cmake.org/u/Andrej730)
#### Post date: [December 18, 2025, 1:44pm UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408/3 "2025-12-18T13:44:55Z")
I like the idea and totally get the sentiment - when library had 10 dependencies to be built and to use it later you also need to provide them all over again. But not sure how to organize this properly.
Maybe some kind of list of `_ROOT` paths should be exported, but to a separate file, next to `-config.cmake` - so it can can be always discarded to keep hardcoded absolute paths out of the installation.
And this auto-find feature preferably should be opt-in since it might confuse typical cmake user - to avoid situations when user is providing dependencies using PATH as usual, but installation keeps preferring some cached path.
Or maybe user can enable it during installation, not during package consumption, but it creates a precedent when the same installed package might behave differently, which is probably better to avoid.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 9, 2026, 5:25am UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408/4 "2026-02-09T05:25:39Z")
VTK does this by [optionally including a file in its `-config.cmake` file](https://gitlab.kitware.com/vtk/vtk/-/blob/8a1be1ef9809b0c7076f686e2b8d8f0c3f888a1f/CMake/vtk-config.cmake.in#L150). This file is always present in the build tree, but is only installed for “non-relocatable” installs. [This file ends up setting lots of `_DIR` and `_ROOT` variables](https://gitlab.kitware.com/vtk/vtk/-/blob/master/CMake/vtkInstallCMakePackageHelpers.cmake) it has access to to help find dependencies. Some packages also have other variables that are forwarded (e.g., `Boost_INCLUDE_DIR`).
---
### Author:  [@Peter\_Hill](https://discourse.cmake.org/u/Peter_Hill)
#### Post date: [February 9, 2026, 8:43am UTC](https://discourse.cmake.org/t/best-practice-setting-package-paths-for-find-dependency-in-config-make-files/15408/5 "2026-02-09T08:43:31Z")
Thanks @ben.boeckel , that looks very useful! I can see that it also still lets the user override certain variables. It looks like it basically works how @Andrej730 described.