i'm currently refactoring a C-project, throwing about 1000 warnings at me.
is there a way to highlight and filter these warnings.
(eg make all index warnings red, unused blue, and some other)
most likely some ides can do that, but that's no solution for me.
This is really basic, but I've been using grep...
make 2>&1 | grep --color -iP "\^|warning:|error:|"
just to quickly draw the eye to the error line and offending section pointed to by ^.
I've found other methods over-use colour and you end up with the same problem. I guess you could also inject colour escape sequences with sed.
Try the colorgcc Debian package. There are also three other packages I found: Johannes Schlüter's colorgcc, or this package in German, or this Sourceforge project
Gcc 4.9 seems to have added this feature via the -fdiagnostics-color flag: http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html#index-fdiagnostics-color-246
The warn_summary script is pretty nice
You can get a count of all your warnings, the type and also just print out the warnings without all the other output from gcc.
gcc <...> | tee buildoutput
warn_summary -s 0 -wpass buildoutput
warn_summary -s 0 buildoutput
You could pipe the output of your compile through grep:
make 2> error.txt; grep -e error error.txt
Compiling in emacs gives you some highlighting. Presumable the details are amenable to customization.
Use M-x compile and issue you usual build command (defaults to make -k).
I've been using pretty make, which formats and colorizes gcc output nicely. The indented format for command options is very clear.
I did end up hacking it to swap the deprecated popen2 to subprocess.
This answer is more about the general approach to reworking old C code.
Large volumes of warnings usually are repetitions of the same small group of warnings because of some errors in header files that are included all over the place by other source code files.
If you're refactoring an old C project, quite often most warning come down to various things such as old K'n'R function dec's, previously allowed casts now being highlighted with a warning, using deprecated functions, etc.
Assuming you're using (g)make to build the project, I'd run the compile using the following command:
gmake 2>&1 | tee results
Then you can have a look at the results file and see what are the most popular warnings you're getting. Start with eliminating all existing warnings before getting on to any refactoring of the code base.
Running the make from within vim gives you lots of possibilities to couple the error and warning messages with the source files.
Related
According to Clang doc:
-I < directory >
Add the specified directory to the search path for include files.
I wounder if there a way to add multiple search path on the same directory with one -I command, something like this:
-I"Dir1/SubDir/SubDir/SubDir/{IncludePath1,IncludePath2,IncludePath3}"
My project folder tree (unfortunately) is in a formation that there are 2 main folders for include paths which each one includes many paths for the -I option. This cause the clang command to be very long and i will give an example:
clang (...)
-I"Dir1/SubDir/SubDir/.../SubDir/IncludePath1"
-I"Dir1/SubDir/SubDir/.../SubDir/IncludePath2"
-I"Dir1/SubDir/SubDir/.../SubDir/IncludePath3"
-I"Dir1/SubDir/SubDir/.../SubDir/(And so on...)"
-I"Dir2/SubDir/SubDir/.../SubDir/IncludePath1"
-I"Dir2/SubDir/SubDir/.../SubDir/IncludePath2"
-I"Dir2/SubDir/SubDir/.../SubDir/IncludePath3"
-I"Dir2/SubDir/SubDir/.../SubDir/(And so on...)"
So again i wonder if there a way to tell clang to search with one command multiple search path or maybe make it search within a specific dir
Use options -isysroot and -iwithsysroot:
clang -isysroot"Dir1/SubDir/SubDir/SubDir/" -iwithsysroot"/IncludePath1/" \
-iwithsysroot"/IncludePath2/" -iwithsysroot"/IncludePath3/"
Unfortunately, this solution only works for one main folder and it also makes those include folders system ones, i.e., Clang won't show any warnings for them.
Also, -iwithsysroot is pretty long, so you may not save much typing there :)
But I'm not aware of any better way to do this directly via Clang options.
Although you could always write a shell script to ease the job...
Note. While digging through Clang command line reference trying to find a better solution, I came across option -ivfsoverlay that seems like it maybe could solve your problem.
I wasn't able to make it work, though, but I still decided to leave it here, maybe it'll be useful for you.
Is there a way to change the specs file so that it will pass -march=native if nothing is specified in command line?
Related things in the default specs file is:
*cc1:
%(cc1_cpu)
*cc1_cpu:
%{march=native:%>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
I am not sure how specs works. Simply specifying -march=native before or after %(cc1_cpu) doesn't work. However, this line does take effect because GCC will report error if I put -something_wierd instead of -march=native.
Another thing I noticed is if I put %{march=i386:-something_wierd} before %(cc1_cpu), gcc reports error so looks like -march=i386 is always passed in if nothing is specified, so is there a way to distinguish between nothing specified and -march=i386 in specs file?
BTW, what does %> do? Seems like it is not specified in the documentation.
I am using MinGW's gcc-4.6.2.
Referring to your last question: The gcc 4.6.1 sources (gcc/gcc.c) contain the following comment on %>:
%>S Similar to "%<S", but keep it in the GCC command line.
For the sake of completeness following the comment for %< form the same file:
%<S remove all occurrences of -S from the command line.
Note - this command is position dependent. % commands in the
spec string before this one will see -S, % commands in the
spec string after this one will not.
To answer the first question in short: yes, but ....
... the only generic solution I found has the significant drawback that the -march option will be ignored, so every build is done as if -march=native had been specified. Anyhow there is a workaround to that.
1 The solution (without workaround)
Create a specs-file called let's say specs.nativealways containing:
*cc1_cpu:
%<march=* -march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
When using the specs-file (for example by invoking gcc with the option -specs=specs.nativealways) the build will be done as if -march=native was specified (with the mentioned drawback that any occurrence of option -march=<arch> would have simply been ignored).
2 The workaround
To still by able to override the newly configured default behavior one can use a modified version of the specs-file described above, introducing a new option called -myarch using the same syntax as -march (except for -myarch=native, which won't work, which does not metter as native now is the default).
The modfied specs-file looks like this:
*cc1_cpu:
%<march=* %{myarch=*:%<myarch* -march=%* ; :-march=native %>march=native %:local_cpu_detect(arch) %{!mtune=*:%>mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%>mtune=native %:local_cpu_detect(tune)}
PS: This has been tested with with gcc 4.6.2 on Linux, but should work on MinGW.
While not a direct answer to your question, you can reach a very similar effect by defining CFLAGS and CXXFLAGS in your shell's initialization file. 99% of the Makefiles are sufficiently standard to pick up the environment values and pass the flags to gcc.
*cc1_cpu:
+ %{!march*:-march=native}
According to GNU's documentation
If there are many included files then the rule is split into several lines using \-newline.
After running the following command, why is the output from gcc -M not as expected?
How do I ensure that each dependency appears on a separate line? Thanks for your help in advance.
gcc -Iinc/ -Isrc/ -M -MM src/BitSet.c
BitSet.o: src/BitSet.c \
inc/BitSet.h inc/StdDefs.h
I am using GCC 4.5.2 (MinGW) on Windows.
You came to expect the wrong thing.
If there are many included files then the rule is split into
several lines using \ -newline.
The rule is split if it is longer than a certain length. Nowhere does the documentation say that the rule will be split after each token.
I.e., fault in the expected output, not in the observed output.
Regarding your comment (building a build tool of your own that uses gcc -M output for its dependency tracking)... the output of gcc -M is meant to be parsed by make, using make's parsing rules. If you want to use the output yourself, you will have to follow the same parsing rules - which aren't that difficult to begin with.
I am trying to make a makefile for one cpp file. I've tried googling and none of the examples I've seen have helped... I keep getting errors when I type make. Here is what I have...
Interpreter: Interpreter.o
g++ -o Interpreter Interpreter.o
Interpreter.o: Interpreter.cpp
g++ -c Interpreter.cpp
When I type make I get this error... "'ake: Fatal error: Don't know how to make target `Interpreter.o"
Where am I going wrong?
OK. A few simple things to start with here:
As mentioned in some of the comments, the makefile file must be named properly for make to find it. You can try specifing it manually with the -f flag to verify that it is being found.
Make is one of those few unfortunate languages where whitespace is important. The rules must not have a tab in front of them, and the commands for the rules should all have exactly one tab in front of them. When I checked your code above in the SO editor, it looked like your commands had two tabs at the front instead of one.
If I'm reading those rules right, you need a file named Interpreter.cpp in your working directory for this to work. If you don't have that file, you'll get an error.
If all else fails, try running make with the debugging flag (-d). This should give you more information about the decisions it is making.
I am trying to read some code that has a lot of macros in it. And often the macros are chained. Is there any way to see a version of the file where all the macros have been expanded -- without doing a full run of the preprocessor (which would also do stuff like expand #imports)? This would really help me read the code.
EDIT: Often the macros are defined in other files.
Not sure if there's a way to do this in Xcode, but you can use the compiler, specifically the -E option, which stops processing right after preprocessing.
cc -E foo.c
will print all the preprocessed results on stdout. And
cc -E foo.c -o foo.preproc
will dump the preprocessed output into foo.preproc.
As best I can tell, the answer to my question is that there is no way to do it. The best I can do is do a full precompile, then search for the part of the file that starts after all the #include statements.