Monday, 30 September 2013

Sqlite compiler spam delenda est.

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> 2>stderr.constant;
sort --unique stderr.constant > stderr.unique;
grep -v -F sqlite stderr.unique

This removes the sqlite warnings and shows you only the current warning messages that are actually ~/trunk related.

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 compiler messages that pertain to your code:

make 2>&1 > | tee | grep -v -F -f stderr.unique >&2 2>/dev/null

You can also type this line when you invoke the emacs compile buffer and your C-x ` will continue to work.


Daniel Shahaf kindly mailed me his solution:

When I ran into this problem, I solved it differently: by building sqlite3 as a shared library and pointing configure to that.  Details  here:

# Built from the amalgamation with:
# s=/home/buildslave18/slave18/tools/sqlite; sudo rm -rf $s && sudo mkdir -p $s/include $s/lib && sudo cp sqlite3.h $s/include && sudo gcc -W -Wall -Wextra -Werror -fPIC -shared -o $s/lib/ sqlite3.c -ldl -lpthread
# NOTE: this doesn't create a .la file for libtool, so libtool won't add this library to rpath of binaries compiled against it, so we have to set LD_LIBRARY_PATH below.

That approach is used by the warnings bot:

I suppose there's more than one way to skin a cat.


(who can do './ >/dev/null && ./configure -q && make -s' and
get no output and no warnings)