All targets are checksummed if no
variable is set and target’s ctime differs from the previous one.
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
DJB’s proposal with both stdout and $3 gives that ability to control your desired behaviour. Those who do not capture stdout – failed. Those who create an empty file if no stdout was written – failed.
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.
goredo, together with
apenwarr/redo, rebuilds target
once per run.
has other opinion, that is why its redo-sh.tests/always_rebuild_1
will fail. Rebuilding of always-ed targets even during the same build
process ruins any redo’s usability in practice.
For example if my .h file contains source code’s version number,
git describe’s output and all my other files depends
on that header, then any
redo-ifchange of .o will lead
git describe execution, that is rather heavy. Of course,
because of either hashing or possible
dependants won’t be rebuilt further, but build time will be already
ruined. 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.