Simple module dependency analysis
-
I recently liberated some of my roses from a tangle of bindweed. Boy, that was a 3D-puzzle to solve. The tangle reminded me of the grown dependency structure between modules of a large software project. I'd like to untangle that a little, too.
The project is structured into many library projects, which in the end get linked into multiple executables and test drivers. Extend the features for one executable, and you are likely to break another, or the test drivers, because they are missing a dependency.
Information would help a lot. Which library depends on which other library?
I have found a lot of tools that help me trace dependencies between header files, also e.g. in Creator. But I still haven't seen anything that would help me trace project-wise dependencies.
The steps such a tool would need to do:
- Trace header dependencies
- See which declarations from those headers are actually used
- See in which cpp file(s) implementations for those declarations exist (could be multiple)
- See in which project(s) these cpp files are included
- Trace the dependency between using and used projects for all such dependency pairs
Does any of you know a tool that already can do that (based on .pro files)? Could clang be used to gather the necessary information? Do you have any other ideas?
-
Doxygen can create some dependency graphs for you. However, "See which declarations from those headers are actually used" is a hard problem, you need specialized tool like include-what-you-use to do that
-
So far, the dependency graphs from doxygen I have seen have shown class-level dependencies. That's too fine-grained to get an overview.
I know that "See which declarations from those headers are actually used" is probably the hardest part. But shouldn't an analyzer based e.g. on clang be able to see which symbols are actually used?
-
In fact, IWYU is based on clang. See https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/WhyIWYUIsDifficult.md why it's still hard problem even you have proper C++ parser
-
Does it have to be based on code analysis? How about a tool that tries to combine libraries in different permutations, and see whether the number of unresolved externals change? It could run on a separate machine overnight.
-
Whoa, it will be extremly inefficient, tied to particular build system(s) and won't scale at all for large projects
-
Of course, it scales exponentially. Then again, performance is not my primary concern, if the alternative is no solution at all. And I'm happy with a solution that works on my own build system, although I would welcome a general solution.
But I have an idea how to improve it:
- Auto-generate a .pro file building a dll for each library separately
- Build them and collect the linker output
- Extract symbol dependencies from the linker output
- Locate symbol definitions by parsing the cpp files (or using a tool that offers that)
- See to which projects the cpp files belong
That way you would get first symbol dependency, the cpp file dependency, then project dependency.
-
If you are thinking of symbols in terms of binaries (dlls), the right way of tracking dependencies is analysis of binaries. You need to get lists of public symbols from all libraries linked to your application, demangle them, and then you will be able to check which of them are used in each of your source files.
If you wonder which tools to use for this task, I only know appropriate tools for ELF, not for Windows binaries