# target\_include\_directories behavior with empty value
**URL:** https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867
**Category:** Code
**Created:** [March 2, 2021, 8:59am UTC](https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867 "2021-03-02T08:59:19Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@shr-project](https://discourse.cmake.org/u/shr-project)
#### Post date: [March 2, 2021, 8:59am UTC](https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867/1 "2021-03-02T08:59:19Z")
I’ve already left a comment in commit which was ensuring clean INTERFACE\_INCLUDE\_DIRECTORIES:
[https://gitlab.kitware.com/cmake/cmake/-/commit/af81a3c31b206633742eb13d41c54a9bc807ffea](https://gitlab.kitware.com/cmake/cmake/-/commit/af81a3c31b206633742eb13d41c54a9bc807ffea)
That it doesn’t seem to work right when the value added with target\_include\_directories is actually empty it ends exporting PROJECT\_SOURCE\_DIR.
Recently I’ve noticed this in [CMakeLists.txt: don't include CERES\_INCLUDE\_DIRS if it's empty or not set by shr-project · Pull Request #1808 · cartographer-project/cartographer · GitHub](https://github.com/cartographer-project/cartographer/pull/1808)
When variable used in target\_include\_directories is empty or unset:
```cmake
target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC "${SOME_UNDEFINED_OR_EMPTY_VARIABLE}")
```
the PROJECT\_SOURCE\_DIR ends in INTERFACE\_INCLUDE\_DIRECTORIES/INTERFACE\_SYSTEM\_INCLUDE\_DIRECTORIES.
Is this correct behavior?
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 2, 2021, 2:51pm UTC](https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867/2 "2021-03-02T14:51:33Z")
The [target\_include\_directories](https://cmake.org/cmake/help/v3.20/command/target_include_directories.html) command documents that the specified paths must be either absolute or relative paths. If given a relative path, `target_include_directories` interprets it with respect to the current source directory. The code [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.5/Source/cmTargetIncludeDirectoriesCommand.cxx#L54) determines that an empty string is not an absolute path, and so converts it to an absolute path by prefixing it with the current source directory.
In your use case, the variable reference should not be quoted. CMake’s language does not require quoting variable references to handle spaces in the path. An unquoted variable reference will expand to zero or more non-empty arguments by splitting on `;`. See documentation on [lists](https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#lists).
---
### Author:  [@shr-project](https://discourse.cmake.org/u/shr-project)
#### Post date: [March 2, 2021, 3:04pm UTC](https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867/3 "2021-03-02T15:04:53Z")
> The code [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.19.5/Source/cmTargetIncludeDirectoriesCommand.cxx#L54) determines that an empty string is not an absolute path, and so converts it to an absolute path by prefixing it with the current source directory.
Then why doesn’t it trigger an error like when you add e.g. ‘.’ as relative path?
```auto
target_include_directories(Tutorial PUBLIC ".")
```
```auto
CMake Error in CMakeLists.txt:
Target "Tutorial" INTERFACE_INCLUDE_DIRECTORIES property contains path:
"/OE/projects/cmake/Help/guide/tutorial/Step2/."
which is prefixed in the source directory.
```
similarly
```auto
target_include_directories(Tutorial PUBLIC "..")
```
triggers the same error (except the shown path), but
```auto
target_include_directories(Tutorial PUBLIC "")
```
doesn’t trigger any error nor any warning about unnecessary quotes.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 2, 2021, 3:27pm UTC](https://discourse.cmake.org/t/target-include-directories-behavior-with-empty-value/2867/4 "2021-03-02T15:27:19Z")
The lack of diagnostic on `install(EXPORT)` for this case is a bug. I’ve opened [CMake Issue 21879](https://gitlab.kitware.com/cmake/cmake/-/issues/21879) for this.