Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
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.
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.
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.
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.
Good news: redhat Source-Navigator (runs on Windows too). Of course, compiler switches (mentioned earlier) have superior parsing and I'm not sure how this will handle MFC, Qt and their magic keywords.
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.
http://www.flourish.org/cinclude2dot/
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.
http://www.profactor.co.uk/includemanager.php
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.
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 $#
.dep/%.dep: %.c .dep
(echo $# \\; $(CC) $(IFLAGS) -MM $<) > $# || (rm $#; false)
.dep/%.dep: %.cpp .dep
(echo $# \\; $(CXX) $(IFLAGS) -MM $<) > $# || (rm $#; false)
DEPEND := $(patsubst %.dep,.dep/%.dep,$(OBJ:.o=.dep))
-include $(DEPEND)
(Make sure to change those indents to hardtabs.)
You can also check out makedepend:
http://en.wikipedia.org/wiki/Makedepend
http://www.xfree86.org/current/makedepend.1.html
Understand for C++ should be able to help you: it builds a database that you can access from Perl.
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.
Related
We've been trying unsuccessfully to make VPATH or vpath search directories containing space characters.
My makefile contains:
vpath %cpp RTW/ModelRTW RTW/StandardTests RTW/TestFramework RTW/TestFromFile ../../../CommonCode ../04_Model/DLib/ ../04 Model/ELib/
make -p returns:
.
.
vpath %cpp RTW/ModelRTW:RTW/StandardTests:RTW/TestFramework:RTW/TestFromFile:../../../CommonCode:../04_Model/DLib
I have tried quoting, escaping '\ ' and several other incarnations to no avail.
Any help would be greatfully accepted.
Ed
Sadly, it is a very old known defect, #712, and people have looked in to it a few times since it was reported in 2002.
GNU make doesn't handle spaces in names, and never has.
If you do attempt to patch it you will have a serious challenge ahead, since an enormous number of projects rely on it. Those who need whitespace support move to more advanced build systems. Over the decades there have been many build script tools, but make still sticks around despite many major problems. The make format of tabs and spaces has been annoying developers for almost 40 years.
The source is available, feel free to attempt to patch it if you want. Most developers who try end up giving up or making yet another build script system.
The best way is to write an m-script to copy the file(s) to the build directory where path is space-free.
If you use Simulink then the m-script is invoked at "before_make" hook.
I need to have some of my C++ classes, functions and namespaces renamed as a part of my build script, which is runned by my CI system.
Unfortunatly a simple sad/awk/gsar/... technique is not enough, and I need smart rename refactoring, that carefully analyses my code.
Actually I found out, that CDT C/C++ rename refactoring does, what I need. But it does it from Eclipse IDE. So I need to find a way to start it from command line, and to make it a part of my CI build script.
I know that Eclipse has eclipsec executable, that allowes running some Eclipse functions from command line (see e.g. here).
But I can't find any suitable documentation for functions, CDT exports to command line. The only thing, I found is the this. But it doesn't solve my problem.
So, I need help to run CDT rename refactoring from command line (or someway like that). If it is not possible, may be someone will advice another tool, that can do rename refactoring for C++ from command line ?
Pragmatic Approach
"I need to have renamed as a part of my build script"
This sounds a bit like a design problem. However, I remember having been guilty of the same sin once writing a C++ application on AIX/Win32: most notably, I wanted to be able to link 'conflicting' versions of shared objects. I solved it using a simple preprocessor hack like this:
# makefile
#if($(ALTERNATIVE))
CPPFLAGS+=-DLIBNAMESPACE=MYLIB_ALTERNATIVE
#else
CPPFLAGS+=-DLIBNAMESPACE=MYLIB
#endif
./obj64/%.o: %cpp
xlC++ $(CPPFLAGS) $^ -o %#
Sample source/header file:
namespace MYLIB
{
class LibService :
{
};
}
As you can see, this required only a single
find -iname '*.[hc]pp' -o -iname '*.[hc]' -print0 |
xargs -0 sed -i 's/OldNamespace/MYLIB/g'
Eclipse Automation
You could have a look at eclim, which does most, if not all, of what you describe, however it targets the vim editor.
What eclim boasts, is full eclipse intergration (completion, refactoring, usage search etc.) from an external program. I'm not fully up to speed with the backend of eclim, but I do know that it works with a eclimd server process that exposes the service interface used by the vim plugin.
I suspect you should be able to reuse the code from eclimd if not just use eclim for your purposes.
We are completing a command-line rename tool for C++, that uses compiler accurate parsing and name resolution, including handling of shadowed names. Contact me (see bio) for further details or if you might be interested in a beta.
We have a C/C++ project where we wish to encrypt (with GPG) every single source file, and have make (specifically, GNU Make) seamlessly work (as it does now with unencrypted source).
If we encrypt only the C or C++ files, this seems fairly easy to accomplish with a rule like this:
%.o : %.cc.gpg %.hh
$(GPG) --decrypt $< | $(CXX) $(CFLAGS) -x c++ -c -o $# -
However, if we start encrypting header files, it gets a lot trickier, as the C file may #include any number of headers. So it seems to me that first I need to generate a dependency list, then decrypt every one that is encrypted, and compile. Ideally, the decryption would be done in-memory, rather than leaving decrypted files laying around while compilation takes place.
Some notes, in anticipation of the comments I'll get:
The users' workflow will involve GPG plugins for their editor, but the rest should be as seamless as possible (i.e. traditional commandline-based Linux svn + make + gcc workflow)
We are using subversion for source control. We know and are OK with source being stored as binary blobs (as well as the implications of this, e.g. breaking svn diff)
The subversion repo lives on an encrypted filesystem (LUKS), and access is only through https
This is a management requirement
In my web research of this problem, I've seen a lot of people argue against encrypting every source file. As I said, it's a management requirement. But one thing that is not addressed by these arguments is keeping the source safe from sysadmins. Yes, at some point you have to trust people, but our source is kind of like the recipe to Coke: if it is uncontrolled, it could literally ruin the company. So why take chances?
You have two problems: 1) decrypting files in the build process and 2) keeping the cleartext in RAM. The second is a little out of my field; I'd suggest air-gapped workstations with nightly disc-scrubbing and a really good auditing system, and anyone who points out a flaw in security gets rewarded, not punished. Anyway let's assume you've solved that problem. (At this point you could just decrypt the whole code base and work normally, but let's try to find a tighter solution.)
For the decryption, you're halfway there. Instead of decrypting in the %.o rule I'd break it into separate rules:
%.cc : %.cc.gpg
$(GPG) --decrypt $<
%.o : %.cc %.hh
$(CXX) $(CFLAGS) -x c++ -c -o $# -
Now as you say, all you have to do is generate a dependency list. Then you can expand the first rule to cover encrypted headers and you're golden.
If you're using a civilized compiler like g++, you can (in general) generate a dependency list with g++ -M, and use that to write a "smart" %.o rule such as described here, which will handle all dependency problems automatically and invisibly.
The problem is that you can't use g++ -M at first, because you're in a viscous circle: you don't want to decrypt all of the headers, just the ones you need, so you can't do the decryption until you know which headers you need, but you won't know that until you generate the dependency files, which means running g++, but g++ will pitch an error and quit if a needed header isn't there already.
So we'll cheat. Suppose we have a separate directory full of empty header files with the same names as the real header files (trivial to build/maintain with Make). We can direct g++ (and Make) to look there for any headers it can't find in the usual place. That is not enough to actually compile objects, but it is enough to run g++ -M without error. The dependency list it constructs will be incomplete (because the real headers may #include each other) but it is enough for the first iteration. Make can decrypt those headers, then start over; when the results of g++ -M are the same as the list from the previous iteration, the process is complete, all needed headers have been decrypted and compilation can begin.
Is that outline enough, or do you need help with the nut and bolts?
I'm new to compiling C/C++ with the aid of make. I downloaded an open source project and noticed that there is in the make file CXXSources and CXXObjects. I think I understand roughly what the make file is doing with them but...
I don't have any of the source files listed under CXXSources. Are these like dependences I'm supposed to know how to find? Is there any custom as to what CXXSource is versus just Source?
Added link to project: http://www.fim.uni-passau.de/en/fim/faculty/chairs/theoretische-informatik/projects.html
More specifically, the GML parser, eg. http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gml/gml-parser.tar.gz
It seems to be getting stuck on the line:
gml_to_graph : $(CXXOBJECTS) gml_scanner.o gml_parser.o
$(CXX) -o gml_to_graph_demo $(CXXOBJECTS) gml_parser.o gml_scanner.o -L$(LEDADIR)/lib -lG -lL -lm
The $CXXObjects is defined by
CXXSOURCES = gml_to_graph.cc gml_to_graph_demo.cc
CXXOBJECTS = $(CXXSOURCES:.cc=.o)
So I need gml_to_graph.cc, it seems. Or maybe I'm wrong?
Usually, the variables are set before the point where you see them. This could be
(a) via the environment
(b) before including the quoted makefile
(c) in the quoted makefile, but preceding the location quoted
To see (verbosely) what GNU make takes into account, do:
make -Bn
(it will show everything that _would get executed)
Even more verbose:
make -p all
It will show you all the internal variable expansions.
If you post a link or more information, we will be able to come up with less generic (and hence possibly less confusing) answers
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm working an a very large scale projects, where the compilation time is very long. What tools can I use (preferably open source) on Linux, to find the most heavily included files and that optimize their useages?
Just to be clearer, I need a tool which will, given the dependencies, show me which headers are the most included. By the way, we do use distributed compiling
Check out makdepend
The answers here will give you tools which track #include dependencies. But there's no mention of optimization and such.
Aside: The book "Large Scale C++ Software Design" should help.
Using the Unix philosophy of "gluing together many small tools" I'd suggest writing a short script that calls gcc with the -M (or -MM) and -MF (OUTFILE) options (As detailed here). That will generate the dependency lists for the make tool, which you can then parse easily (relative to parsing the source files directly) and extract out the required information.
Tools like doxygen (used with the graphviz options) can generate dependency graphs for include files... I don't know if they'd provide enough overview for what you're trying to do, but it could be worth trying.
From the root level of the source tree and do the following (\t is the tab character):
find . -exec grep '[ \t]*#include[ \t][ \t]*["<][^">][">]' {} ';'
| sed 's/^[ \t]*#include[ \t][ \t]*["<]//'
| sed 's/[">].*$//'
| sort
| uniq -c
| sort -r -k1 -n
Line 1 get all the include lines.
Line 2 strips off everything before the actual filename.
Line 3 strips off the end of the line, leaving only the filename.
Line 4 and 5 counts each unique line.
Line 6 sorts by line count in reverse order.
Use ccache. It will hash the inputs to a compilation, and cache the results, which will drastically increase the speed of these sorts of compiles.
If you wanted to detect the multiple includes, so that you could remove them, you could use makedepend as Iulian Șerbănoiu suggests:
makedepend -m *.c -f - > /dev/null
will give a warning for each multiple include.
Bash scripts found in the page aren't good solution. It works only on simple project. In fact, in large project, like discribe in header page, C-preprocessor (#if, #else, ...) are often used. Only good software more complex, like makedepend or scons can give good informations. gcc -E can help, but, on large project, its result analysis is a wasting time.
If you wish to know which files are included most of all, use this bash command:
find . -name '.cpp' -exec egrep '^[:space:]#include[[:space:]]+["<][[:alpha:][:digit:]_.]+[">]' {} \;
| sort | uniq -c | sort -k 1rn,1
| head -20
It will display top 20 files ranked by amount of times they were included.
Explanation: The 1st line finds all *.cpp files and extract lines with "#include" directive from it. The 2nd line calculates how many times each file was included and the 3rd line takes 20 mostly included files.
IIRC gcc could create dependency files.
You might want to look at distributed compiling, see for example distcc
This is not exactly what you are searchng for, and it might not be easy to setup, but may be you could have a look at lxr : lxr.linux.no is a browseable kernel tree.
In the search box, if you enter a filename, it will give you where it is included.
But this is still guessing, and it does not track chained dependencies.
Maybe
strace -e trace=open -o outfile make
grep 'some handy regex to match header'