### Author:  [@MathiasMagnus](https://discourse.cmake.org/u/MathiasMagnus)
#### Post date: [March 18, 2020, 1:39pm UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/1 "2020-03-18T13:39:15Z")
Hi!
I have a build where a system package config file is picked up even though it should not be. Having read the docs on what the config file search logic is, it could only possible find it if the search of `` is recurisve, however this word does not appear in the docs anywhere.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 18, 2020, 3:05pm UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/2 "2020-03-18T15:05:51Z")
With 3.17, you should be able to pass `--debug-find` to have CMake output why it is finding the package in question.
`CMAKE_PREFIX_PATH` is not searched recursively, but specific paths are used relative to each entry to find other paths. For example, `lib` is looked in for `find_library` calls. If it is finding a `foo-config.cmake` package under it, it is in a path that is search specifically by CMake under the prefixes it is given.
---
### Author:  [@MathiasMagnus](https://discourse.cmake.org/u/MathiasMagnus)
#### Post date: [March 18, 2020, 3:17pm UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/3 "2020-03-18T15:17:41Z")
Thanks @ben.boeckel, that was a lifesaver. I installed the 3.17-rc3 for this sole purpose and debugged the issue. It’s picking up the package config file, because of a `bin` path, which is then shaved off and made a system-wide base of config file lookup. This rule 5. of [Search Procedure](https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure) is intricate, to say the least.
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [May 13, 2020, 10:04am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/4 "2020-05-13T10:04:53Z")
I was about to ask for the same kind of question.
We have a set of customarily build dependencies which are installed in a common prefix, say:
`/my/local/install` but each of them have their own subdir, say: `/my/local/install/pkg/x.y.z` so that `pkg-config.cmake` is located in `/my/local/install/pkg/x.y.z/cmake`.
I want my main build to find all those dependencies (with `find_xxx`) but in order to make that work
I have to append [https://cmake.org/cmake/help/latest/variable/CMAKE\_MODULE\_PATH.html](https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html) with every `/my/local/install/pkg/x.y.z/cmake` I have (and I have a bunch of them) is there any reason CMake does not recurse into a specified CMAKE\_MODULE\_PATH ?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 14, 2020, 7:38pm UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/5 "2020-05-14T19:38:07Z")
> [@erk](#):
>
> is there any reason CMake does not recurse into a specified CMAKE\_MODULE\_PATH ?
CMake would have to know where to stop. Recursively searching `/usr` is not something I want CMake to ever do (permission errors for various bits, finding documentation/examples instead of Real Code, etc.).
One thing that might be useful here is glob support in `CMAKE_PREFIX_PATH` (`CMAKE_MODULE_PATH` is more sensitive and probably not as viable IMO)?
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [May 15, 2020, 6:56am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/6 "2020-05-15T06:56:29Z")
> [@ben.boeckel](#):
>
> CMake would have to know where to stop. Recursively searching `/usr` is not something I want CMake to ever do (permission errors for various bits, finding documentation/examples instead of Real Code, etc.).
Yes right. I suppose cmake can only look into \*.cmake files. My need concerns find package and cmake config files which ought to be called that way.
> [@ben.boeckel](#):
>
> One thing that might be useful here is glob support in `CMAKE_PREFIX_PATH` ( `CMAKE_MODULE_PATH` is more sensitive and probably not as viable IMO)?
Agreed. Globbing would be nice, and may be doing it in a programmatic way would
avoid repetitive globbing.
I.e. we could do that with:
`cmake_prefix_path_add(PREFIX /my/local/install GLOB '*.cmake')`
or
`cmake prefix_path_add(PREFIX /my/local/install GLOB_RECURSE '*.cmake')`
those call would populate CMAKE\_PREFIX\_PATH accordingly.
Which makes me think (out at loud) I can already do that with a user defined macro, I’ll give it a shot.
By the way why do you think CMAKE\_MODULE\_PATH is more sensitive?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [May 15, 2020, 11:29am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/7 "2020-05-15T11:29:07Z")
> [@erk](#):
>
> Yes right. I suppose cmake can only look into \*.cmake files. My need concerns find package and cmake config files which ought to be called that way.
I think you misunderstood. I don’t want CMake even _looking_ under `/usr/share/docs/examples` (or whatever) for _anything_. It shouldn’t even get to the “does this filename match?” part of its logic.
> [@erk](#):
>
> `cmake_prefix_path_add(PREFIX /my/local/install GLOB '*.cmake')`
Maybe I’m misunderstanding. Why is `list(APPEND CMAKE_PREFIX_PATH "/static/*/*")` not sufficient?
> [@erk](#):
>
> By the way why do you think CMAKE\_MODULE\_PATH is more sensitive?
I think it is way more common to be able to say "I have a forest of prefixes that all match `/static/*/*`. I can’t say that it feels that common for files I want CMake to search in with `include`.
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [May 18, 2020, 6:15am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/8 "2020-05-18T06:15:33Z")
> [@ben.boeckel](#):
>
> > [@erk](#):
> >
> > `cmake_prefix_path_add(PREFIX /my/local/install GLOB '*.cmake')`
>
> Maybe I’m misunderstanding. Why is `list(APPEND CMAKE_PREFIX_PATH "/static/*/*")` not sufficient?
It is, no doubt.
My point was that we may want to enforce the fact that the globbing expression is resolved only once.
And not each time CMake uses CMAKE\_PREFIX\_PATH content.
I think this is the same idea as yours:
> [@ben.boeckel](#):
>
> I don’t want CMake even _looking_ under `/usr/share/docs/examples` (or whatever) for _anything_ . It shouldn’t even get to the “does this filename match?” part of its logic.
So if I may summarize:
1. we may want to have a way to specify globbing expression in CMAKE\_PREFIX\_PATH
which collect all paths used by find\_xxx command
2. we don’t want that for CMAKE\_MODULE\_PATH
I would add that globbing expression in CMAKE\_PREFIX\_PATH should ideally be processed only once.
---
### Author:  [@hsattler](https://discourse.cmake.org/u/hsattler)
#### Post date: [May 18, 2020, 7:46am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/9 "2020-05-18T07:46:27Z")
If a developer wants globbing, that can already be done with one additional line, right?
---
### Author:  [@erk](https://discourse.cmake.org/u/erk)
#### Post date: [May 18, 2020, 8:13am UTC](https://discourse.cmake.org/t/is-cmake-prefix-path-recursively-searched/817/10 "2020-05-18T08:13:59Z")
Little more than one line I guess but yes it is already doable with something like:
```cmake
file(GLOB_RECURSE CUSTOM_PATHS
LIST_DIRECTORIES true
"/my/custom/path/**/*")
```
then you’ll have to filter out files since (AFAIK) one cannot list “only directories”.
but yes a macro/function would do the job.