# FindBoost difference between Boost\_INCLUDE\_DIR and Boost\_INCLUDE\_DIRS

**URL:** https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855
**Category:** Code
**Created:** [March 25, 2020, 9:07am UTC](https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855 "2020-03-25T09:07:26Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![MonkeyBreaker](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/0ea827/32.png) [@MonkeyBreaker](https://discourse.cmake.org/u/MonkeyBreaker)
#### Post date: [March 25, 2020, 9:07am UTC](https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855/1 "2020-03-25T09:07:26Z")

</div>

Hi everyone,

Question is about the difference of using `Boost_INCLUDE_DIR` and `Boost_INCLUDE_DIRS` to indicate where boost header files are in the system.

As I understood so far from the documentation and from different posts on SO and other forums:

- Boost\_INCLUDE\_DIR is cached after a first run of cmake in the project
- Boost\_INCLUDE\_DIRS is set each time that cmake is run in the project

From the examples in the documentation, `Boost_INCLUDE_DIRS` is the variable used to indicate where boost header files are in the system.

But my question is, if we decided to use `Boost_INCLUDE_DIR`, should results be different that with `Boost_INCLUDE_DIRS` ?

Because in our library, we decided to go with `Boost_INCLUDE_DIR`, it worked so far. But one developer encountered an error because `Boost_INCLUDE_DIR` was empty (it was not Boost\_INCLUDE\_DIR-NOT\_FOUND) and `Boost_INCLUDE_DIRS` was correctly set.

Our CMake scripts only does the following:

```auto
find_package(Boost 1.56 REQUIRED)
include_directories(${Boost_INCLUDE_DIR})

```

Thank you for any insights on the issue and have a nice day.

Julián

---

<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: [March 25, 2020, 11:36am UTC](https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855/2 "2020-03-25T11:36:34Z")

</div>

`Boost_INCLUDE_DIR` is the directory Boost found for itself. This does not happen for `BoostConfig.cmake` based searches. `Boost_INCLUDE_DIRS` is the list of include directories needed to use Boost. This should include any directories to dependencies needed.

---

<div class="post-metadata">

### Author: ![MonkeyBreaker](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/m/0ea827/32.png) [@MonkeyBreaker](https://discourse.cmake.org/u/MonkeyBreaker)
#### Post date: [March 25, 2020, 12:30pm UTC](https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855/3 "2020-03-25T12:30:29Z")

</div>

Thank you for the answer !

I understand, but maybe the current naming or description of the variables is a bit confuse, what do you think ?

Because even in forums, the confusion happen, see:

- [this](https://stackoverflow.com/a/3813010): tells users to go with `Boost_INCLUDE_DIR`
- [this](https://stackoverflow.com/a/6646518): tells users to go with `Boost_INCLUDE_DIRS`

Both answer are accepted ones.

In my opinion the confusion comes from the variable name.

Anyway, we’ll change from `Boost_INCLUDE_DIR` to `Boost_INCLUDE_DIRS` in our library.

Julián

---

<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: [March 25, 2020, 12:56pm UTC](https://discourse.cmake.org/t/findboost-difference-between-boost-include-dir-and-boost-include-dirs/855/4 "2020-03-25T12:56:00Z")

</div>

It’s a typical pattern that things directly found are singular while aggregates which may include dependencies is plural. Since `config.cmake` files don’t need to actually search for anything, the singular variants tend to not exist and only the plural versions are “end results” of the `find_package` call. There are some older modules which have not migrated to this usage pattern however.
