X-Git-Url: http://www.git.cypherpunks.ru/?a=blobdiff_plain;f=doc%2Ffaq.texi;h=3bf832ef88541374f3df71b35688a9bacc90a231;hb=b3dd8c5cdab414de32a69956b54f0d5e4fdcfeb8;hp=16fadafa01bef6604c7be428c6a64e5d1ac8e483;hpb=5ca39bfc0b769607db3f84213fc7f16f0c4019fa;p=goredo.git

diff --git a/doc/faq.texi b/doc/faq.texi
index 16fadaf..3bf832e 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -4,8 +4,8 @@
 @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.
+All targets are checksummed if target's @file{ctime} differs from the
+previous one, or @env{REDO_INODE_NO_TRUST} environment variable is set.
 @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
@@ -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.