+ ../default.do
+* redo-dot -- dependency DOT graph generator. For example to visualize
+ your dependencies with GraphViz: >
+ $ redo target [...] # to assure that **/.redo/*.dep are filled up
+ $ redo-dot target [...] > whatever.dot
+ $ dot -Tpng whatever.dot > whatever.png # possibly add -Gsplines=ortho
+
+FAQ *goredo-faq*
+
+ Hashing and stamping~
+
+All targets are checksummed if their 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.
+
+* Aggregate targets and willing to be out-of-date ones just must not
+ produce empty output files. apenwarr/*, redo-c and goredo
+ implementations consider non existing file as an out-of-date target
+* If you really wish to produce an empty target file, just touch $3
+
+DJB's proposal with both stdout and $3 gives that ability to control
+your desired behaviour. Those who does not capture stdout -- failed.
+Those who creates 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 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 just
+remove foo/.redo/bar.dep.
+
+ Does redo-always always rebuilds target?~
+
+goredo, together with apenwarr/redo, rebuilds target once per run.
+Always rebuilds during every redo invocation, but only once during it
+building. http://news.dieweltistgarnichtso.net/bin/redo-sh.html#why-built-twice
+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.
+