# Help debugging transitive INTERFACE\_INCLUDE\_DIRECTORIES

**URL:** https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752
**Category:** Usage
**Created:** [February 12, 2021, 10:54am UTC](https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752 "2021-02-12T10:54:03Z")
**Posts on this page:** 4
**Page:** 1

<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: [February 12, 2021, 10:54am UTC](https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752/1 "2021-02-12T10:54:03Z")

</div>

Is it possible to get a whole information about target properties/include dirs and all dependencies (include transitive) using the brand new cmake-file-api(7)?

Hello everyone. I try to determine why some transitive INTERFACE\_DIRECTORIES doesn’t inherited by some targets in project with large amount of CMake targets and relatively tangled dependencies graph.  
While reading the cmake-file-api(7) manual, I found that the `build/.cmake/api/v1/query/codemodel-v2` has some useful info, but it doesn’t show the whole props graph.  
As that I found that there are the `target-<name>-<hash>.json` files with relevant, but insufficient to determine which part of deps graph broke the transitiveness:

```auto
          "includes" :
            [
                {
                    "backtrace" : 5,
                    "path" : "/home/user/proj/include"
                },
                {
                    "backtrace" : 5,
                    "path" : "/home/afails/proj/build/include"
                },
                {
                    "backtrace" : 5,
                    "path" : "/home/afails/proj/src/core/include"
                }
            ],

```

N.B. I also thought about the `--graphviz` parameter but it doesn’t provides that information

---

<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 12, 2021, 6:07pm UTC](https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752/2 "2021-02-12T18:07:14Z")

</div>

Cc: @brad.king

---

<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: [February 15, 2021, 5:04pm UTC](https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752/3 "2021-02-15T17:04:07Z")

</div>

All the per-target information generated by the file-api’s `codemodel-v2` object is documented in the [cmake-file-api(7)](https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html#codemodel-version-2-target-object) manual. It is meant to report what is placed in the generated buildsystem, not the raw inputs to the generators.

I suggest adding a direct `target_link_libraries` dependency between whatever target is not getting the include directories and whatever target exposes them as `INTERFACE_INCLUDE_DIRECTORIES`. Make sure that works first. Then move the dependency down through your expected graph one step at a time until you find where it breaks. That will tell you which dependency is not expressed as `PUBLIC` or `INTERFACE` somewhere in that chain.

---

<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: [February 16, 2021, 8:11pm UTC](https://discourse.cmake.org/t/help-debugging-transitive-interface-include-directories/2752/4 "2021-02-16T20:11:58Z")

</div>

Thank you all for replies!  
I also think that the [GLOBAL\_DEPENDS\_DEBUG\_MODE](https://cmake.org/cmake/help/latest/prop_gbl/GLOBAL_DEPENDS_DEBUG_MODE.html) could help me with this problem, and I also propose this for adding into cmake-file-api 😊