Next: , Previous: , Up: Top  


Hashing and stamping

All targets are checksummed if no REDO_INODE_NO_TRUST environment variable is set and target’s ctime differs from the previous one. apenwarr/redo gives many reasons why every time checksumming is bad, but in my opinion in practice all of them do not apply.

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-stamp.

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[23] algorithms demonstrate us.

goredo includes 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.

Can removed .do lead to permanent errors of its non existence?

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.

Does redo-always always rebuilds target?

goredo, together with apenwarr/redo, rebuilds target once per run. redo-sh 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, that is git describe’s output and all my other files depends on that header, then any redo-ifchange of .o will lead to git describe execution, that is rather heavy. Of course, because of either hashing or possible redo-stamp-ing its 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.

Next: , Previous: , Up: Top