@anchor{Stamping}
@section Hashing and stamping
-All targets are checksummed if no @env{REDO_INODE_NO_TRUST} environment
-variable is set and target's @file{ctime} differs from the previous one.
-@command{apenwarr/redo} gives
+All targets are checksummed if target's size, @code{ctime}/@code{mtime}
+differs from the previous one (depending on @ref{OOD, @env{$REDO_INODE_TRUST}}
+value). @command{apenwarr/redo} gives
@url{https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps, many reasons}
why every time checksumming is bad, but in my opinion in practice all of
them do not apply.
@item If you really wish to produce an empty target file, just touch @file{$3}
@end itemize
-DJB's proposal with both @file{stdout} and @file{$3} gives that ability
-to control your desired behaviour. Those who do not capture
-@file{stdout} -- failed. Those who create an empty file if no
-@file{stdout} was written -- failed.
+Those who create an empty file if no @file{stdout} was written -- failed
+implementation.
redo is a tool to help people. Literally all targets can be safely
@code{redo-stamp < $3}-ed, reducing false positive out-of-dates. Of
@section Does redo-always always rebuilds target?
-@command{goredo}, together with @command{apenwarr/redo}, rebuilds target
-once per @strong{run}.
-@url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice, redo-sh}
-has other opinion, that is why its @file{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 @file{.h} file contains source code's version number,
-that is @command{git describe}'s output and all my other files depends
-on that header, then any @command{redo-ifchange} of @file{.o} will lead
-to @command{git describe} execution, that is rather heavy. Of course,
-because of either hashing or possible @command{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
+By definition, it should be built always, as
+@url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice,
+redo-sh} and @command{redo-c} implementations do. But that ruins the
+whole redo usability, potentially rebuilding everything again and again.
+@command{apenwarr/redo} and @command{goredo} tries to build
+always-targets only once per @strong{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 @file{.do}, as
@command{apenwarr/redo} already suggests.
+
+@section 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 @command{goredo}
+does this as a shameful hack and only for always-targets, still existing
+in the wild. The whole @command{redo-always} idea is considered harmful.
+
+If you wish to run something and decide if it must OOD the toplevel
+targets, then just run @command{redo} to forcefully rebuild it and then
+run the ordinary top level targets.