doc/faq.texi

   1 @node FAQ
   2 @cindex FAQ
   3 @unnumbered FAQ
   4
   5 @anchor{Stamping}
   6 @cindex hashing
   7 @cindex stamping
   8 @section Hashing and stamping
   9
  10 All targets are checksummed if target's size, @code{ctime}/@code{mtime}
  11 differs from the previous one (depending on @ref{OOD, @env{$REDO_INODE_TRUST}}
  12 value). @command{apenwarr/redo} gives
  13 @url{https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps, many reasons}
  14 why every time checksumming is bad, but in my opinion in practice all of
  15 them do not apply.
  16
  17 @itemize
  18 @item Aggregate targets and willing to be out-of-date ones just must not
  19   produce empty output files. @command{apenwarr/*}, @command{redo-c} and
  20   @command{goredo} implementations treat non existing file as an
  21   out-of-date target
  22 @item If you really wish to produce an empty target file, just touch @file{$3}
  23 @end itemize
  24
  25 Those who create an empty file if no @file{stdout} was written -- are
  26 failed implementations.
  27
  28 redo is a tool to help people. Literally all targets can be safely
  29 @code{redo-stamp < $3}-ed, reducing false positive out-of-dates. Of
  30 course, with the correct @file{stdout}/@file{$3} working and placing
  31 necessary results in @file{$3}, instead of just silently feeding them in
  32 @command{redo-stamp}.
  33
  34 redo implementations already automatically record -ifchange on
  35 @file{.do} files and -ifcreate on non-existing @file{.do} files. So why
  36 they can not record @command{redo-stamp} the same way implicitly? No,
  37 Zen of Python is not applicable there, because -ifchange/-ifcreate
  38 contradicts it already.
  39
  40 Modern cryptographic hash algorithms and CPUs are so fast, that even all
  41 read and writes to or from hard drive arrays can be easily checksummed
  42 and transparently compressed, as ZFS with LZ4/Zstandard and
  43 Skein/BLAKE[23] algorithms demonstrate us.
  44
  45 @command{goredo} includes @command{redo-stamp}, that really records the
  46 stamp in the @file{.rec} file, but it does not play any role later. It
  47 is stayed just for compatibility.
  48
  49 @section Can removed .do lead to permanent errors of its non existence?
  50
  51 Yes, because dependency on it was recorded previously. Is it safe to
  52 assume that @file{.do}-less target now is an ordinary source-file? I
  53 have no confidence in such behaviour. So it is user's decision how to
  54 deal with it, probably it was just his inaccuracy mistake. If you really
  55 want to get rid of that dependency knowledge for @file{foo/bar} target,
  56 then just remove @file{foo/.redo/bar.rec}.
  57
  58 @section Does redo-always always rebuilds target?
  59
  60 By definition, it should be built always, as
  61 @url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice,
  62 redo-sh} and @command{redo-c} implementations do. But that ruins the
  63 whole redo usability, potentially rebuilding everything again and again.
  64 @command{apenwarr/redo} and @command{goredo} tries to build
  65 always-targets only once per @strong{run}, as a some kind of optimization.
  66
  67 For example if you need to rebuild TeX documents (case mentioned in
  68 redo-sh's FAQ) until all references and numbers are ready, then you must
  69 naturally expectedly explicitly use while cycle in your @file{.do}, as
  70 @command{apenwarr/redo} already suggests.
  71
  72 @section What to do with OOD targets, that has not changed their output?
  73
  74 How to prevent building of targets, who depend on the OOD target, that
  75 produced the same output? If the target is already decided to be OOD,
  76 then the whole tree becomes OOD too. It is clear, simple, reliable and
  77 honest way of do-ing things.
  78
  79 Building of the lower level OOD target first is unfair and dishonest
  80 thing to do, because probably top level target, being the OOD, won't be
  81 dependant on lower level target anymore at all. Actually @command{goredo}
  82 does this as a shameful hack and only for always-targets, still existing
  83 in the wild. The whole @command{redo-always} idea is considered harmful.
  84
  85 If you wish to run something and decide if it must OOD the toplevel
  86 targets, then just run @command{redo} to forcefully rebuild it and then
  87 run the ordinary top level targets.