apenwarr-redo/t/s60-stamp/stampy.do

echo $$ >>stampy.log
redo-ifchange inp bob
cat inp
cd ..
redo-stamp <s60-stamp/inp
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			`echo $$ >>stampy.log`
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud? 2010-12-11 03:29:38 -08:00			`redo-ifchange inp bob`
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			`cat inp`
redo-always/redo-ifcreate/redo-stamp: work inside chdir(). If someone cd's to another directory and then runs redo-always, we weren't adding to the right target. 2010-12-11 23:00:53 -08:00			`cd ..`
t/660-stamp: don't run at the same time as other tests in redo -j. flush-cache can cause files affected by redo-stamp to get rebuilt unnecessarily, which the test is specifically trying to validate. Since other tests run flush-cache at random times when using -j, this would cause random test failures. 2018-10-12 04:39:09 -04:00			`redo-stamp <s60-stamp/inp`