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

echo n2-$2
echo $2 >>$2.count
echo $2 >>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
Change definitions of $1,$2,$3 to match djb's redo. If you use "redo --old-args", it will switch back to the old (apenwarr-style) arguments for now, to give you time to update your .do scripts. This option will go away eventually. Note: minimal/do doesn't understand the --old-args option. If you're using minimal/do in your project, keep using the old one until you update your use of $1/$2, and then update to the new one. apenwarr-style default.o.do: $1 foo $2 .o $3 whatever.tmp djb-style default.o.do: $1 foo.o $2 foo $3 whatever.tmp apenwarr-style foo.o.do: $1 foo.o $2 "" $3 whatever.tmp djb-style foo.o.do: $1 foo.o $2 foo.o (I think?) $3 whatever.tmp 2011-12-31 02:45:38 -05:00			`echo n2-$2`
			`echo $2 >>$2.count`
			`echo $2 >>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`