# CMAKE\_PREFIX\_PATH absent from locations considered for Config module

**URL:** https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685
**Category:** Usage
**Tags:** os:windows
**Created:** [February 3, 2021, 4:47pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685 "2021-02-03T16:47:17Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![MathiasMagnus](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mathiasmagnus/32/431_2.png) [@MathiasMagnus](https://discourse.cmake.org/u/MathiasMagnus)
#### Post date: [February 3, 2021, 4:47pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685/1 "2021-02-03T16:47:17Z")

</div>

While maintaining the OpenCL repository CMake and CI scripts I came across an issue I can’t untangle.

When building one of the components (OpenCL-ICD-Loader) that relies on another (OpenCL-Headers) I first build the dependency and install it designating some `CMAKE_INSTALL_PREFIX`.

```auto
cmake -G "Visual Studio 16 2019" -A %BIN% -T v140 -D CMAKE_C_FLAGS=%C_FLAGS% -D CMAKE_C_EXTENSIONS=ON -D CMAKE_INSTALL_PREFIX=%GITHUB_WORKSPACE%/external/OpenCL-Headers/install -S %GITHUB_WORKSPACE%/external/OpenCL-Headers -B %GITHUB_WORKSPACE%/external/OpenCL-Headers/build
# Invoke install
...
  -- Installing: D:/a/OpenCL-ICD-Loader/OpenCL-ICD-Loader/external/OpenCL-Headers/install/share/cmake/OpenCLHeaders/OpenCLHeadersTargets.cmake
  -- Installing: D:/a/OpenCL-ICD-Loader/OpenCL-ICD-Loader/external/OpenCL-Headers/install/share/cmake/OpenCLHeaders/OpenCLHeadersConfig.cmake
  -- Installing: D:/a/OpenCL-ICD-Loader/OpenCL-ICD-Loader/external/OpenCL-Headers/install/share/cmake/OpenCLHeaders/OpenCLHeadersConfigVersion.cmake

```

So far so good. After that I configure my component and provide the location of the header package using the very same location I used for installation and feeding it to `CMAKE_PREFIX_PATH`.

I try finding the package like this:

```cmake
find_package(OpenCLHeaders)
if (TARGET OpenCL::Headers)
  target_link_libraries (OpenCL PUBLIC OpenCL::Headers)
else ()
  # Uninteresting fallback mechanism
endif ()

```

This all works flawlessly locally.

```auto
C:\Kellekek\Kitware\CMake\3.19.0-rc2\bin\cmake.exe --debug-find -G "Visual Studio 16 2019" -A x64 -T v142 -D BUILD_TESTING=ON -D CMAKE_PREFIX_PATH=C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install -S ../.. -B .

...
CMake Debug Log at CMakeLists.txt:121 (find_package):
  find_package considered the following paths for OpenCLHeaders.cmake
...
  CMAKE_PREFIX_PATH variable [CMAKE_FIND_USE_CMAKE_PATH].

    C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install
..
  find_package considered the following locations for the Config module:

    C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install/OpenCLHeadersConfig.cmake
    C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install/openclheaders-config.cmake
    C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install/share/cmake/OpenCLHeaders/OpenCLHeadersConfig.cmake

  The file was found at

    C:/Users/mate/Source/Repos/OpenCL-Headers/.vscode/install/share/cmake/OpenCLHeaders/OpenCLHeadersConfig.cmake

```

However the same when invoked in GitHub Actions on a GitHub hosted Windows runner [spews out hordes of paths](https://github.com/MathiasMagnus/OpenCL-ICD-Loader/runs/1823678450?check_suite_focus=true#step:8:1070) I never provided, but not the one I gave in `CMAKE_PREFIX_PATH`:

```auto
cmake --debug-find -G "Visual Studio 16 2019" -A %BIN% -T v140 -D BUILD_TESTING=ON -D CMAKE_C_FLAGS=%C_FLAGS% -D CMAKE_C_EXTENSIONS=ON -D CMAKE_INSTALL_PREFIX=%GITHUB_WORKSPACE%/install -D CMAKE_PREFIX_PATH=%GITHUB_WORKSPACE%/external/OpenCL-Headers/install -S %GITHUB_WORKSPACE% -B %GITHUB_WORKSPACE%/build

...
  CMAKE_PREFIX_PATH variable [CMAKE_FIND_USE_CMAKE_PATH].

    D:/a/OpenCL-ICD-Loader/OpenCL-ICD-Loader/external/OpenCL-Headers/install
...
  find_package considered the following locations for the Config module:

    C:/Program Files/MongoDB/Server/4.4/OpenCLHeadersConfig.cmake
    C:/Program Files/MongoDB/Server/4.4/openclheaders-config.cmake
    C:/aliyun-cli/OpenCLHeadersConfig.cmake
    C:/aliyun-cli/openclheaders-config.cmake
    C:/ProgramData/kind/OpenCLHeadersConfig.cmake
    C:/ProgramData/kind/openclheaders-config.cmake
    C:/vcpkg/OpenCLHeadersConfig.cmake
    C:/vcpkg/openclheaders-config.cmake
    C:/cf-cli/OpenCLHeadersConfig.cmake
    C:/cf-cli/openclheaders-config.cmake
...

```

On a slightly related note I don’t know why this works locally in the first place as the docs suggest that `<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/ (U)` is only searched on Unix-like OS-es, however the issue here is likely something else. Why is my `CMAKE_PREFIX_PATH` not being searched in the GitHub Actions case?

---

<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: [February 3, 2021, 5:14pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685/2 "2021-02-03T17:14:31Z")

</div>

`CMAKE_PREFIX_PATH` is my normal mechanism as well. Some things to look at:

- does `CMAKE_PREFIX_PATH` contain the path you expect (seems to only have an entry on the `D:` drive rather than under `C:/Users/mate`)
  - You can use `--trace-expand` and grep for `CMAKE_PREFIX_PATH` to see if some code is overwriting the `-D` value you gave instead of appending/prepending/whatever.

- vcpkg does some interposition into the `find_package` logic; is that interfering here at all?

---

<div class="post-metadata">

### Author: ![MathiasMagnus](https://discourse.cmake.org/user_avatar/discourse.cmake.org/mathiasmagnus/32/431_2.png) [@MathiasMagnus](https://discourse.cmake.org/u/MathiasMagnus)
#### Post date: [February 3, 2021, 6:11pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685/3 "2021-02-03T18:11:09Z")

</div>

Thanks @ben.boeckel for the suggestions. In the GA runner, the exhaustive list doesn’t contain my path, which is easy to spot, because it’s on `D:\` whereas all the system paths listed are on `C:\`. They seem like to be related to `PATH` , as every entry is a pre-installed tool.

I’m not using Vcpkg at all (that entry may be misleading), I didn’t provide the toolchain file on the command-line so it better not interfere with anything.

Can environment variables alter the behavior of `CMAKE_PREFIX_PATH`? Can any override it?

---

<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: [February 3, 2021, 6:48pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685/4 "2021-02-03T18:48:45Z")

</div>

There is also an [envvar of the same name](https://cmake.org/cmake/help/latest/envvar/CMAKE_PREFIX_PATH.html). I’m not _quite_ sure how they interact together though (probably just which is preferred for search order).

I’d trace the CMake code to see what, if anything, is overriding your `CMAKE_PREFIX_PATH` cache entry. Note that any local variable setting will shadow the cache.

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 3, 2021, 8:53pm UTC](https://discourse.cmake.org/t/cmake-prefix-path-absent-from-locations-considered-for-config-module/2685/5 "2021-02-03T20:53:22Z")

</div>

> [@MathiasMagnus](#):
>
> On a slightly related note I don’t know why this works locally in the first place as the docs suggest that `<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/ (U)` is only searched on Unix-like OS-es, however the issue here is likely something else.

That is not the case. The docs also say this (emphasis added by me):

> Directories above marked with (`W` ) are intended for installations on Windows where the prefix may point at the top of an application’s installation directory. Those marked with (`U` ) are intended for installations on UNIX platforms where the prefix is shared by multiple packages. **This is merely a convention, so all (`W` ) and (`U` ) directories are still searched on all platforms.**