c++ dependency - Tool to track#include dependencies
analysis graph (10)
Thanks to KeithB. I looked up the docs for cl.exe (VS2008) and found the /showIncludes flag. From the IDE, this can be set from the property page of any CPP file.
Any good suggestions? Input will be the name of a header file and output should be a list (preferably a tree) of all files including it directly or indirectly.
Understand for C++ should be able to help you: it builds a database that you can access from Perl.
For a heavy weight solution, you should check out Doxygen. It scans through your code base and comes up with a website, effectively, that documents your code. One of the many things it shows is include trees.
If you were looking to be able to plug the output of this tool into some other process, then this may not work for you (although Doxygen does output to other formats, I'm not real familiar with that feature). If you simply want to eyeball the dependencies, though, it should work great.
I've played around with a tool called cinclude2dot. It was pretty useful in getting a handle on a rather large codebase when I came to work here. I've actually thought about integrating it into our daily build eventually.
If you have access to GCC/G++, then the
-M option will output the dependency list. It doesn't do any of the extra stuff that the other tools do, but since it is coming from the compiler, there is no chance that it will pick up files from the "wrong" place.
First, cinclude2dot.pl is a perl script which analyses C/C++ code and produces a #include dependency graph as a dot file for input into graphviz.
If you don't want to go the way of that sort of manual tool, then the hands-down by far winner is in my opinion a tool known as "IncludeManager" from ProFactor.
There's a free trial, and it is awesome. It's a plug-in for Visual Studio that's totally integrated so double clicking on something over here takes you to the place where it is included over there.
Tooltip mouseovers give you all the info you would want, and it lets you drill down / up, remove whole subtrees you don't care about, view representations other than graphs, cycle through a list of matches for this and that, it's wonderful.
If you're quick about it, you can refactor the #include structure of a large projects before the trial runs out. Even so, it doesn't cost much, about $35 per license.
For what it does, it is just about perfect. Not only #include graphs but also cross project dependencies of shared files, impact on build times, detailed properties in grids, perfect.
cscope (http://cscope.sourceforge.net/) does this in a standalone xterm, and also can be used inside your favorite editor - it has great emacs and vi/vim support.
Building on KeithB's answer, here is GNUmake syntax to automatically 1) generate the dependency files, 2) keep them up to date, and 3) use them in your makefile:
.dep: mkdir [email protected] .dep/%.dep: %.c .dep (echo [email protected] \\; $(CC) $(IFLAGS) -MM $<) > [email protected] || (rm [email protected]; false) .dep/%.dep: %.cpp .dep (echo [email protected] \\; $(CXX) $(IFLAGS) -MM $<) > [email protected] || (rm [email protected]; false) DEPEND := $(patsubst %.dep,.dep/%.dep,$(OBJ:.o=.dep)) -include $(DEPEND)
(Make sure to change those indents to hardtabs.)
The answer to your question is that newer sqlite3 has improved performance, use that.
This answer Why is SQLAlchemy insert with sqlite 25 times slower than using sqlite3 directly? by SqlAlchemy Orm Author has 100k inserts in 0.5 sec, and I have seen similar results with python-sqlite and SqlAlchemy. Which leads me to believe that performance has improved with sqlite3