Subject: Re: Potentially unnecessary redoing of targets

From: spacefrogg <[email-masked]>
Date: Mon, 12 Jan 2026 12:53:40 +0000

You are describing two different cases.

In the first, the execution of `2.do` has already started (due to OOD).  
This could result in anything, even in dropping `1` as a dependency 
entirely.  The assumption that `redo-ifchange 1` resulting in an 
unchanged output ALSO results in not changing the output of `2` is just 
wrong.  Anything could happen depending on what the content of `1` means 
in the context of executing `2.do`.  It could even result in never 
running `1.do`.  The (implicit) contract is that ONLY `2.do` may decide 
what the content of `1` means.  In addition, there is also the 
(implicit) assumption that the meaning of `1` should only depend on the 
current content of `1` and not on whether/how it has changed from the 
previous run.

In the second case, OOD has just determined that there is nothing to do. 
  You only reached that case by (nearly) compromising the build flow, 
which is (or should be) out of scope for the design of redo.  Actually, 
you would have reached the same case by running `redo-ifchange 1; 
redo-ifchange 2`. There, the first `redo-ifchange` also "clears" the OOD 
state of `1`.

So, to make the distinction clear: In your case, which was running 
`redo-ifchange 2`, `2` being OOD because of `1` just results in running 
`2.do`.  That's it.  Whether that means to also run `1.do` is entirely 
up to the program in `2.do`.  Running `1.do` is not the result of `1` 
being determined OOD but of the command `redo-ifchange 1` being part of 
`2.do`.

The two cases have nothing in common, really.

Kind regards,
Michael