apenwarr-redo/t/curse/default.n2.do

echo n2-$1
echo $1 >>$1.count
echo $1 >>in.countall

# we deliberately use 'redo' here instead of redo-ifchange, because this *heavily*
# stresses redo's locking when building in parallel.  We end up with 100
# different targets that all not only depend on this file, but absolutely must
# acquire the lock on this file, build it atomically, and release the lock.
redo countall
Add t/curse, a multi-level dependency build that really aggravates redo. ...because it seems my locking isn't very good. It exposes annoying problems involving rebuilding the same files more than once, screwing up stamp files with redo -j, and being unnecessarily slow when checking dependencies. So it's a pretty good test considering how simple it is. Didn't add it to t/all.do yet, because it would fail. 2010-11-19 00:28:16 -08:00			`echo n2-$1`
t/curse: test to make sure the same file isn't generated more than once. redo currently passes this when running serially, but not in parallel. 2010-11-19 00:55:36 -08:00			`echo $1 >>$1.count`
t/curse: test that 'redo' (not redo-ifchange) always redoes a command. ...if the containing .do file is getting redone at all, of course. Currently passes in serial mode, fails in parallel. 2010-11-19 02:10:44 -08:00			`echo $1 >>in.countall`
Switch to using a separate lockfile per target. The previous method, using fcntl byterange locks, was very efficient and avoided unnecessarily filesystem metadata churn (ie. creating/deleting inodes). Unfortunately, MacOS X (at least version 10.6.5) apparently has a race condition in its fcntl locking that makes it unusably unreliable (http://apenwarr.ca/log/?m=201012#13). My tests indicate that if you only ever lock a single byterange on a file, the race condition doesn't cause a problem. So let's just use one lockfile per target. Now "redo -j20 test" passes for me on both MacOS and Linux. This doesn't measurably affect the speed on Linux, at least, in my tests. The bad news: it's hard to safely delete those lockfiles when we're done with them, so they tend to accumulate in the .redo dir. 2010-12-14 02:25:17 -08:00
			`# we deliberately use 'redo' here instead of redo-ifchange, because this heavily`
			`# stresses redo's locking when building in parallel. We end up with 100`
			`# different targets that all not only depend on this file, but absolutely must`
			`# acquire the lock on this file, build it atomically, and release the lock.`
t/curse: test that 'redo' (not redo-ifchange) always redoes a command. ...if the containing .do file is getting redone at all, of course. Currently passes in serial mode, fails in parallel. 2010-11-19 02:10:44 -08:00			`redo countall`