From: Sergey Matveev <stargrave@stargrave.org>
Date: Mon, 21 Jun 2021 13:33:40 +0000 (+0300)
Subject: redo-always thoughts
X-Git-Tag: v1.5.0~1
X-Git-Url: http://www.git.cypherpunks.ru/?p=goredo.git;a=commitdiff_plain;h=2b3f40572950d717efa76f23fb5108af56904907

redo-always thoughts
---

diff --git a/doc/faq.texi b/doc/faq.texi
index 16fadaf..2098b77 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -56,20 +56,31 @@ then just remove @file{foo/.redo/bar.rec}.
 
 @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 build 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 wrong.
+
+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.