Help debugging transitive INTERFACE_INCLUDE_DIRECTORIES

Usage
1

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:

          "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

2

Cc: @brad.king

3

All the per-target information generated by the file-api’s codemodel-v2 object is documented in the cmake-file-api(7) 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.

1 Like
4

Thank you all for replies!
I also think that the GLOBAL_DEPENDS_DEBUG_MODE could help me with this problem, and I also propose this for adding into cmake-file-api :blush: