Next: State, Previous: Install, Up: goredo   [Index]

Hashing and stamping ¶

All targets are checksummed if target’s size, ctime/mtime differs from the previous one (depending on $REDO_INODE_TRUST value). apenwarr/redo gives many reasons why every time checksumming is bad, but in my opinion in practice all of them do not apply.

• Aggregate targets and willing to be out-of-date ones just must not produce empty output files. apenwarr/*, redo-c and goredo implementations treat non existing file as an out-of-date target
• If you really wish to produce an empty target file, just touch $3

Those who create an empty file if no stdout was written – are failed implementations.

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 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 is not applicable there, because -ifchange/-ifcreate contradicts 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 .dep 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 remove foo/.redo/bar.dep.

Does redo-always always rebuilds target? ¶

By definition, it should be built always, as redo-sh and redo-c implementations do. But that ruins the whole redo usability, potentially rebuilding everything again and again. apenwarr/redo and 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.

What to do with OOD targets, that has not changed their output? ¶

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