This website requires JavaScript.
CODE
0x495fab29
Explore
Sign in
forks
/
apenwarr-redo
Watch
1
Star
0
Fork
You've already forked apenwarr-redo
0
Code
Issues
Pull requests
Projects
Releases
Packages
Wiki
Activity
Actions
f4b4c400b2
apenwarr-redo
/
t
/
660-stamp
/
stampy.do
5 lines
83 B
Text
Raw
Normal View
History
Unescape
Escape
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/*: rearrange tests into numbered directories. It was getting way too ad-hoc in there. Let's reorganize the tests so that there's a good, obvious, suggested sequence to run them in.
2012-02-08 00:33:00 -05:00
redo-stamp <660-stamp/inp
Reference in a new issue
Copy permalink