# \<PackageName\>\_ROOT vs \<PackageName\>\_ROOT\_DIR

**URL:** https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931
**Category:** Code
**Created:** [November 10, 2024, 7:01pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931 "2024-11-10T19:01:20Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![petk](https://discourse.cmake.org/user_avatar/discourse.cmake.org/petk/32/4555_2.png) [@petk](https://discourse.cmake.org/u/petk)
#### Post date: [November 10, 2024, 7:01pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931/1 "2024-11-10T19:01:20Z")

</div>

Hello, there is `<PackageName>_ROOT_DIR` variable mentioned in the [documentation](https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names) and I’m not sure I understand why should this variable be used if there is already automatic CMake handling done by `<PackageName>_ROOT` variable.

Is this meant to be `<PackageName>_ROOT` or should packages actually use the `_ROOT_DIR` somehow in addition to `<PackageName>_ROOT`?

Thanks.

---

<div class="post-metadata">

### Author: ![retif](https://discourse.cmake.org/user_avatar/discourse.cmake.org/retif/32/1776_2.png) [@retif](https://discourse.cmake.org/u/retif)
#### Post date: [November 10, 2024, 10:25pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931/2 "2024-11-10T22:25:23Z")

</div>

Interesting question, I haven’t thought about this before. But the way I read the documentation now actually makes sense to me: `Xxx_ROOT_DIR` is the _result_ variable that is (_should be, for the sake of consistency/convention_) set by the `FindXxx.cmake` module when/if `Xxx` is found, and [Xxx\_ROOT](https://cmake.org/cmake/help/latest/variable/PackageName_ROOT.html) is the variable that `FindXxx.cmake` module will use to get a list of paths/prefixes of potential `Xxx` whereabouts to know where to look for it.

So, in other words (_and with the right “order of use”_):

1. `Xxx_ROOT` contains the path(s) of where to look for `Xxx`;
2. `FindXxx.cmake` attempts to find `Xxx` using those paths;
3. If `Xxx` is found, then `Xxx_ROOT_DIR` is set.

---

<div class="post-metadata">

### Author: ![leha-bot](https://discourse.cmake.org/user_avatar/discourse.cmake.org/leha-bot/32/921_2.png) [@leha-bot](https://discourse.cmake.org/u/leha-bot)
#### Post date: [November 15, 2024, 1:46pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931/3 "2024-11-15T13:46:54Z")

</div>

@brad.king , maybe we should mention it in cmake-developer(7) and related docs?

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 15, 2024, 1:52pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931/4 "2024-11-15T13:52:55Z")

</div>

> [@leha-bot](#):
>
> maybe we should mention it in cmake-developer(7)

Yes, I’d welcome a clarification to the documentation of `Xxx_ROOT_DIR` in that manual.

@retif’s explanation of the purpose of each variable is correct. However, in general it is not expected that `Xxx_ROOT_DIR` is set by a find module. It’s documented as a naming convention for modules that choose to provide such a variable.

---

<div class="post-metadata">

### Author: ![petk](https://discourse.cmake.org/user_avatar/discourse.cmake.org/petk/32/4555_2.png) [@petk](https://discourse.cmake.org/u/petk)
#### Post date: [November 16, 2024, 8:59pm UTC](https://discourse.cmake.org/t/packagename-root-vs-packagename-root-dir/12931/5 "2024-11-16T20:59:50Z")

</div>

I see. Thanks @retif for the clarification. PR opened here [https://gitlab.kitware.com/cmake/cmake/-/merge\_requests/10006](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10006)

There is also Xx\_ROOT\_DIR mentioned in the [Mastering CMake](https://cmake.org/cmake/help/book/mastering-cmake/chapter/Finding%20Packages.html) but I didn’t find it sooner.