All targets are checksummed if target’s size,
differs from the previous one (depending on
why every time checksumming is bad, but in my opinion in practice all of
them do not apply.
goredoimplementations consider non existing file as an out-of-date target
Those who create an empty file if no stdout was written – failed implementation.
redo is a tool to help people. Literally all targets can be safely
redo-stamp < $3-ed, reducing false positive out-of-dates. Of
course, with the correct stdout/$3 working and placing
necessary results in $3, instead of just silently feeding them in
redo implementations are already automatically record -ifchange on
.do files and -ifcreate on non-existing .do files. So why
they can not record
redo-stamp the same way implicitly? No,
Zen of Python does not applicable there, because -ifchange/-ifcreate
contradict it already.
Modern cryptographic hash algorithms and CPUs are so fast, that even all read and writes to or from hard drive arrays can be easily checksummed and transparently compressed, as ZFS with LZ4/Zstandard and Skein/BLAKE algorithms demonstrate us.
redo-stamp, that really records the
stamp in the .rec file, but it does not play any role later. It
is stayed just for compatibility.
Yes, because dependency on it was recorded previously. Is it safe to assume that .do-less target now is an ordinary source-file? I have no confidence in such behaviour. So it is user’s decision how to deal with it, probably it was just his inaccuracy mistake. If you really want to get rid of that dependency knowledge for foo/bar target, then just remove foo/.redo/bar.rec.
By definition, it should be built always, as
redo-c implementations do. But that ruins the
whole redo usability, potentially rebuilding everything again and again.
goredo tries to build
always-targets only once per run, as a some kind of optimization.
For example if you need to rebuild TeX documents (case mentioned in
redo-sh’s FAQ) until all references and numbers are ready, then you must
naturally expectedly explicitly use while cycle in your .do, as
apenwarr/redo already suggests.
How to prevent building of targets, who depend on the OOD target, that produced the same output? If the target is already decided to be OOD, then the whole tree becomes OOD too. It is clear, simple, reliable and honest way of do-ing things.
Building of the lower level OOD target first is unfair and dishonest
thing to do, because probably top level target, being the OOD, won’t be
dependant on lower level target anymore at all. Actually
does this as a shameful hack and only for always-targets, still existing
in the wild. The whole
redo-always idea is considered harmful.
If you wish to run something and decide if it must OOD the toplevel
targets, then just run
redo to forcefully rebuild it and then
run the ordinary top level targets.