apenwarr-redo/t/flush-cache.sh

#!/bin/sh
#echo "Flushing redo cache..." >&2
(
	echo ".timeout 5000"
	echo "pragma synchronous = off;"
	echo "update Files set checked_runid=null, " \
	     "       changed_runid=changed_runid-1, " \
	     "       failed_runid=failed_runid-1;"
) | sqlite3  "$REDO_BASE/.redo/db.sqlite3"
flush-cache: run it as a separate program, not using 'source' That way it doesn't clutter up 'redo -x' as much. 2010-12-08 20:16:26 -08:00			`#!/bin/sh`
t/deps/dirtest: test correct dependency checking for targets named 'dirname' We had a bug (fixed in the previous commit) where doing 'redo-ifchange dirname' (which runs dirname/all.do) would not create the stamp correctly, so that it would always show up as dirty. It's a little bit complicated to simulate, but this does it. 2010-11-22 22:50:54 -08:00			`#echo "Flushing redo cache..." >&2`
Switch state.py to use sqlite3 instead of filesystem-based stamps. It passes all tests when run serialized, but still gives weird errors (OperationalError: database is locked) when run with -j5. sqlite3 shouldn't be barfing just because the database is locked, since the default timeout is 5 seconds, and it's dying way faster than that. 2010-12-07 02:17:22 -08:00			`(`
sqlite3: configure the timeout explicitly. In flush-cache.sh, we have to do this, because the sqlite3 command-line tool sets it to zero. Inevitably during parallel testing, it'll end up contending for a lock, and we really want it to wait a bit. In state.py, it's not as important since the default is nonzero. But python-sqlite3's default of 5 seconds makes me a little too nervous; I can imagine a disk write waiting for more than 5 seconds sometime. So let's use 60 instead. 2010-12-08 21:40:42 -08:00			`echo ".timeout 5000"`
flush-cache.sh: for speed, disable sqlite's synchronous mode. 2010-12-09 01:43:13 -08:00			`echo "pragma synchronous = off;"`
			`echo "update Files set checked_runid=null, " \`
Don't wipe the timestamp when a target fails to redo. It's really a separate condition. And since we're not removing the target file in case of error - we update it atomically, and keeping it is better than losing it - there's no reason to wipe the timestamp in that case either. However, we do need to know that the build failed, so that anybody else (especially in a parallel build) who looks at that target knows that it died. So add a separate flag just for that. 2010-12-10 20:53:31 -08:00			`" changed_runid=changed_runid-1, " \`
If a user manually changes a generated file, don't ever overwrite it. That way the user can modify an auto-generated 'compile' script, for example, and it'll stay modified. If they delete the file, we can then generate it for them again. Also, we have to warn whenever we're doing this, or people might think it's a bug. 2010-12-10 22:42:33 -08:00			`" failed_runid=failed_runid-1;"`
Switch state.py to use sqlite3 instead of filesystem-based stamps. It passes all tests when run serialized, but still gives weird errors (OperationalError: database is locked) when run with -j5. sqlite3 shouldn't be barfing just because the database is locked, since the default timeout is 5 seconds, and it's dying way faster than that. 2010-12-07 02:17:22 -08:00			`) \| sqlite3 "$REDO_BASE/.redo/db.sqlite3"`