CMakeLists.txt files in subdirectories are unconditionally included in analysis

[Jonathan B. Coe]

CMakeLists.txt files in subdirectories, like those from submodules, are included in analysis regardless of whether they are in the transitive-include graph of the top-level CMakeLists.txt file.

src/Input.cpp L 267 will pull in any file named CMakeLists.txt.

This results in misdiagnosis of ambiguous includes in projects like https://github.com/jbcoe/polymorphic_value which include the popular Catch testing framework.

[Peter Bindels]

You should be able to use the --ignore flag to exclude a tree of files from the analysis. This is typically for build folders, but may be of use in this case too.

I do wonder why it should not be ambiguous? If an include you do have cannot decide between a local include and an imported one, that is still actually ambiguous.

[Jonathan B. Coe]

Thanks, I'll give that a go. Sounds like a useable workaround.

However, I don't think there's any ambiguity.

#include <catch.hpp>

will only possibly find one header file which is on the include path.

The include path is set to ./externals/catch/include

I'm not sure why cpp-dependencies thinks this is ambiguous.

./externals/catch/include/catch.hpp
./externals/catch/single_include/catch.hpp

are the options it puts forward but the second path is not on any include path (the project I referenced has only one source file).

I'm keen to start using cpp-dependencies as part of our build toolset. Do let me know if I can provide any more useful information.

[Peter Bindels]

It finds it ambiguous because you include "catch.hpp" which could be either of those. And it's correct at that - it could be either. Changing your include paths or reordering dependencies could have the result of including the other header with the resulting hidden change in behavior. In this particular case one of them is generated from the other, but in other cases they may be subtly incompatible and result in very hard to find bugs, or cause build instability when adding correct dependencies.

The tool is meant for large code bases, so the issues it finds may seem silly in a small example. Imagine having 100.000 files and unqualified include statements like this that may find one out of three headers depending on where you include it. Suddenly it's very important to have unique includes - not necessarily unique file names, but include statements that can only go to one header.

A concrete way of fixing / avoiding this is to ignore one of the two paths, to get one of the two to change his name, or to include it such that it's obvious which one you include. For example, `#include "single_include/catch.hpp" would not be ambiguous. Given the size of your problem I wouldn't mind it too much.

[Jonathan B. Coe]

Thanks, that's clear and unambiguous.
We've started using this tool on a much larger code base and already find it very useful.