Gabriela Gibson wrote: > Because sqlite produces ~50000 extra letters of bumpf per compile that often > obscures actually important compiler messages, I've not been as diligent as > I should have been about reading compiler messages. A lot the time I get > lucky > and it doesn't matter, but I also got caught out by that. > > Here is how to get rid of all the noise and make your compiler output useful > once again: > > First we take a snapshot of the 'native' compiler messages that come > with the trunk: > > make 1>stdout.report 2>stderr.constant; \ > sort --unique stderr.constant > stderr.unique | grep -v sqlite > > This removes the sqlite warnings and shows you only the current warning > messages > that are actually ~/trunk related.
Cool. I like tricks like this. At the end of my build script I print a slightly condensed summary of all the warnings that were produced, by piping the (stderr) log file content through the following command: grep -B1 'subversion/.*: warning:' | sed -e 's,/home/julianfoad/src/subversion[^/]*/,,' \ -e "s/[‘’]/'/g" \ -e 's/ warning: / /' (The second sed expression replaces the curly quotes that my UK-localized GCC outputs with plain ASCII quote marks to make it less likely to display wrongly on screen.) > Any subsequent compiles that are started with the line below will use the > generated stderr.unique file to filter output and remove every compiler > message > that is 'native' to the trunk, leaving just the messages that pertain to > your code: > > make > stdout.report 2> >(tee stderr.report | while read line; do echo > $line | grep -F -- $line" stderr.unique 2> /dev/null; if [ $? = 1 ]; > then echo "$line" >&2; fi; done) I expect you were wondering if grep could do this by itself. It can: make > stdout.report 2> >(tee stderr.report | grep -v -F -f stderr.unique >&2) - Julian > You can also type this line when you invoke the emacs compile buffer and your > C-x ` will continue to work.
