apenwarr-redo/t/clean.do

redo example/clean curse/clean deps/clean "space dir/clean" stamp/clean
rm -f c c.c c.c.c c.c.c.b c.c.c.b.b d mode1 makedir.log chdir1 deltest2 \
	hello [by]ellow *.o *~ .*~ *.log CC LD passfail silence silence.do \
	touch1 touch1.do always1 ifcreate[12].dep ifcreate[12]
rm -rf makedir
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up. 2010-12-11 02:17:51 -08:00			`redo example/clean curse/clean deps/clean "space dir/clean" stamp/clean`
			`rm -f c c.c c.c.c c.c.c.b c.c.c.b.b d mode1 makedir.log chdir1 deltest2 \`
Add a redo-always command: it adds an "always dirty" dependency to your target. This is mostly useless except when combined with redo-stamp... I think. 2010-12-11 07:02:45 -08:00			`hello [by]ellow .o ~ .~ .log CC LD passfail silence silence.do \`
Add a redo-ifcreate test. Turns out we weren't testing this one at all, which is a shame, because it totally didn't work. 2010-12-11 23:42:31 -08:00			`touch1 touch1.do always1 ifcreate[12].dep ifcreate[12]`
$3 and stdout no longer refer to the same file. This is slightly inelegant, as the old style echo foo echo blah chmod a+x $3 doesn't work anymore; the stuff you wrote to stdout didn't end up in $3. You can rewrite it as: exec >$3 echo foo echo blah chmod a+x $3 Anyway, it's better this way, because now we can tell the difference between a zero-length $3 and a nonexistent one. A .do script can thus produce either one and we'll either delete the target or move the empty $3 to replace it, whichever is right. As a bonus, this simplifies our detection of whether you did something weird with overlapping changes to stdout and $3. 2010-12-11 00:29:04 -08:00			`rm -rf makedir`