# Right way to look for include files in standard system directories?

**URL:** https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071
**Category:** Usage
**Created:** [October 26, 2020, 3:44pm UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071 "2020-10-26T15:44:05Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![tomoreilly](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/t/439d5e/32.png) [@tomoreilly](https://discourse.cmake.org/u/tomoreilly)
#### Post date: [October 26, 2020, 3:44pm UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071/1 "2020-10-26T15:44:05Z")

</div>

Pardon my very newbie question - I want cmake to look in “standard” system locations for installed third-party headers - how to do that in a portable way? The variable [CMAKE\_SYSTEM\_INCLUDE\_PATH](https://cmake.org/cmake/help/v3.3/variable/CMAKE_SYSTEM_INCLUDE_PATH.html) looks promising, e.g. as a “hint” to find\_file(), but on my ubuntu 18.03 system CMAKE\_SYSTEM\_INCLUDE\_PATH just contains /usr/include/X11. Do I have to manually include “/usr/local/include” in the hints to find\_file()?  
Thanks!

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [October 26, 2020, 5:57pm UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071/2 "2020-10-26T17:57:46Z")

</div>

Hi Tom, I think [CMAKE\_INCLUDE\_PATH](https://cmake.org/cmake/help/latest/variable/CMAKE_INCLUDE_PATH.html) might be the place to put this.  
It sounds like your CMake script is using `find_file()` directly. You could use PATHS or HINTS of find\_file() directly in your CMake script, or use CMAKE\_INCLUDE\_PATH to more generically add include search path for all the find\_file().

I run into this kind of issue for example when using Homebrew on MacOS, needing to add the Homebrew location like this.

---

<div class="post-metadata">

### Author: ![tomoreilly](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/t/439d5e/32.png) [@tomoreilly](https://discourse.cmake.org/u/tomoreilly)
#### Post date: [October 26, 2020, 6:11pm UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071/3 "2020-10-26T18:11:09Z")

</div>

Thanks @scivision. So how/where does CMAKE\_INCLUDE\_PATH get set to a “reasonable” value for the host where you are building, e.g. on MacOS? Is there some way that cmake can detect that? That is the part I think I am missing…

---

<div class="post-metadata">

### Author: ![robert.maynard](https://discourse.cmake.org/user_avatar/discourse.cmake.org/robert.maynard/32/4_2.png) [@robert.maynard](https://discourse.cmake.org/u/robert.maynard)
#### Post date: [October 26, 2020, 7:46pm UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071/4 "2020-10-26T19:46:19Z")

</div>

All the find commands including `find_file` will search `/usr/local` on Linux. This is done as `/usr/local` is contained in `CMAKE_SYSTEM_PREFIX_PATH`.

For example if we have the following code:

```cmake
find_file(FakeFileVar FakeFile.xyz)

```

We can use CMake 3.17+ and to verify the searching with `cmake -B <build_dir> --debug-find` and looking at the output. As shown below we can see CMake searching `/usr/local/include`

```auto
Running with debug output on for the `find` commands.
CMake Debug Log at CMakeLists.txt:7 (find_file):
  find_file called with the following settings:

    VAR: FakeFileVar
    NAMES: "FakeFile.xyz"
    Documentation: Path to a file.
    Framework
      Only Search Frameworks: 0
      Search Frameworks Last: 0
      Search Frameworks First: 0
    AppBundle
      Only Search AppBundle: 0
      Search AppBundle Last: 0
      Search AppBundle First: 0
    CMAKE_FIND_USE_CMAKE_PATH: 1
    CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH: 1
    CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH: 1
    CMAKE_FIND_USE_CMAKE_SYSTEM_PATH: 1

  find_file considered the following locations:

    /usr/local/sbin/FakeFile.xyz
    /usr/local/bin/FakeFile.xyz
    /usr/sbin/FakeFile.xyz
    /usr/bin/FakeFile.xyz
    /sbin/FakeFile.xyz
    /bin/FakeFile.xyz
    /usr/games/FakeFile.xyz
    /usr/local/games/FakeFile.xyz
    /usr/local/include/x86_64-linux-gnu/FakeFile.xyz
    /usr/local/include/FakeFile.xyz
    /usr/local/FakeFile.xyz
    /usr/include/x86_64-linux-gnu/FakeFile.xyz
    /usr/include/FakeFile.xyz
    /usr/FakeFile.xyz
    /include/x86_64-linux-gnu/FakeFile.xyz
    /include/FakeFile.xyz
    /opt/cmake-3.17/include/x86_64-linux-gnu/FakeFile.xyz
    /opt/cmake-3.17/include/FakeFile.xyz
    /opt/cmake-3.17/FakeFile.xyz
    /usr/X11R6/include/x86_64-linux-gnu/FakeFile.xyz
    /usr/X11R6/include/FakeFile.xyz
    /usr/X11R6/FakeFile.xyz
    /usr/pkg/include/x86_64-linux-gnu/FakeFile.xyz
    /usr/pkg/include/FakeFile.xyz
    /usr/pkg/FakeFile.xyz
    /opt/include/x86_64-linux-gnu/FakeFile.xyz
    /opt/include/FakeFile.xyz
    /opt/FakeFile.xyz
    /usr/include/X11/FakeFile.xyz

  The item was not found.

```

---

<div class="post-metadata">

### Author: ![michael\_ch](https://discourse.cmake.org/user_avatar/discourse.cmake.org/michael_ch/32/2744_2.png) [@michael\_ch](https://discourse.cmake.org/u/michael_ch)
#### Post date: [September 6, 2022, 9:29am UTC](https://discourse.cmake.org/t/right-way-to-look-for-include-files-in-standard-system-directories/2071/5 "2022-09-06T09:29:22Z")

</div>

It has been a long time since the question was posted but I am leaving this one just for reference. I have a blog post describing step-by-step almost what you (or anyone else) were trying to do.  
I don’t know if it is the perfect example, but here it is: [Shared lib to be used by client programs with CMake](https://michae9.wordpress.com/2022/09/01/shared-lib-to-be-used-by-client-programs-with-cmake/)

p.s.: sorry for posting a link to my blog but the post is way too big to repost it here.
