doc/faq.texi

   1 @node FAQ
   2 @unnumbered FAQ
   3
   4 @anchor{Stamping}
   5 @section Hashing and stamping
   6
   7 All targets are checksummed if their @file{ctime} differs from the
   8 previous one. @command{apenwarr/redo} gives
   9 @url{https://redo.readthedocs.io/en/latest/FAQImpl/#why-not-always-use-checksum-based-dependencies-instead-of-timestamps, many reasons}
  10 why every time checksumming is bad, but in my opinion in practice all of
  11 them do not apply.
  12
  13 @itemize
  14 @item Aggregate targets and willing to be out-of-date ones just must not
  15   produce empty output files. @command{apenwarr/*}, @command{redo-c} and
  16   @command{goredo} implementations consider non existing file as an
  17   out-of-date target
  18 @item If you really wish to produce an empty target file, just touch @file{$3}
  19 @end itemize
  20
  21 DJB's proposal with both @file{stdout} and @file{$3} gives that ability
  22 to control your desired behaviour. Those who do not capture
  23 @file{stdout} -- failed. Those who create an empty file if no
  24 @file{stdout} was written -- failed.
  25
  26 redo is a tool to help people. Literally all targets can be safely
  27 @code{redo-stamp < $3}-ed, reducing false positive out-of-dates. Of
  28 course, with the correct @file{stdout}/@file{$3} working and placing
  29 necessary results in @file{$3}, instead of just silently feeding them in
  30 @command{redo-stamp}.
  31
  32 redo implementations are already automatically record -ifchange on
  33 @file{.do} files and -ifcreate on non-existing @file{.do} files. So why
  34 they can not record @command{redo-stamp} the same way implicitly? No,
  35 Zen of Python does not applicable there, because -ifchange/-ifcreate
  36 contradict it already.
  37
  38 Modern cryptographic hash algorithms and CPUs are so fast, that even all
  39 read and writes to or from hard drive arrays can be easily checksummed
  40 and transparently compressed, as ZFS with LZ4/Zstandard and
  41 Skein/BLAKE[23] algorithms demonstrate us.
  42
  43 @command{goredo} includes @command{redo-stamp}, that really records the
  44 stamp in the @file{.dep} file, but it does not play any role later. It
  45 is stayed just for compatibility.
  46
  47 @section Can removed .do lead to permanent errors of its non existence?
  48
  49 Yes, because dependency on it was recorded previously. Is it safe to
  50 assume that @file{.do}-less target now is an ordinary source-file? I
  51 have no confidence in such behaviour. So it is user's decision how to
  52 deal with it, probably it was just his inaccuracy mistake. If you really
  53 want to get rid of that dependency knowledge for @file{foo/bar} target,
  54 then just remove @file{foo/.redo/bar.dep}.
  55
  56 @section Does redo-always always rebuilds target?
  57
  58 @command{goredo}, together with @command{apenwarr/redo}, rebuilds target
  59 once per @strong{run}.
  60 @url{http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice, redo-sh}
  61 has other opinion, that is why its @file{redo-sh.tests/always_rebuild_1}
  62 will fail. Rebuilding of always-ed targets even during the same build
  63 process ruins any redo's usability in practice.
  64
  65 For example if my @file{.h} file contains source code's version number,
  66 that is @command{git describe}'s output and all my other files depends
  67 on that header, then any @command{redo-ifchange} of @file{.o} will lead
  68 to @command{git describe} execution, that is rather heavy. Of course,
  69 because of either hashing or possible @command{redo-stamp}-ing its
  70 dependants won't be rebuilt further, but build time will be already
  71 ruined. If you need to rebuild TeX documents (case mentioned in
  72 redo-sh's FAQ) until all references and numbers are ready, then you must
  73 naturally expectedly explicitly use while cycle in your @file{.do}, as
  74 @command{apenwarr/redo} already suggests.