Subject: Re: Potentially unnecessary redoing of targets

From: Niklas Böhm <[email-masked]>
Date: Mon, 12 Jan 2026 16:12:57 +0100

Thanks for your response.  In general, I want to say that `2` is not ood 
because `1` did not change after completion of `1.do`, hence we would 
never have to start it.  The state when `2.do` is executing is in fact 
not ood, but because we determined `1` to be ood (as 1.do that changed), 
we run `2.do` anyways.  What I would suggest is to check, once more, if 
the targets actually did change their content before launching `2.do`.

I see that currently the problem is that the ood checking goes as 
follows (with redo-ifchange -d):
[48985] dbg  ood: 2 checking
[48985] dbg  ood: 2 -> 2.do: checking
[48985] dbg  ood: 2 -> 2.do: same inode
[48985] dbg  ood: 2 -> 2.do: is source
[48985] dbg  ood: 2 -> 1: checking
[48985] dbg  ood: 2 -> 1: inode differs
[48985] dbg  ood: 2 -> 1: same hash
[48985] dbg  ood: . 1 checking
[48985] dbg  ood: . 1 -> 1.do: checking
[48985] dbg  ood: . 1 -> 1.do: inode differs
[48985] dbg  ood: . 1 -> 1.do: hash differs
[48985] dbg  ood: . 1: true
[48985] dbg  ood: 2 -> 1: ood
[48985] dbg  ood: 2: true

I want to make the claim that `2` is not necessarily ood at that point, 
as we could first redo `1` and then check if the output differs before 
determining `2` to be ood.  As the build file `2.do` did not change, we 
know that its dependencies do not change; hence in my opinion it is a 
forgone conclusion to say that `2` is ood only because `1.do` has a 
differing hash, but actually `1` itself does not.

I'll admit that it might be an involved change in the code base and will 
also make redo itself change its behavior (as you lose the transitivity 
property for ood detection), but in my eyes it would be correct to check 
the direct targets of the .do file, instead of cascading the ood 
property.  This would also make the build system minimal

Anyways, thanks for reading all of this text, I hope my point became a 
little clearer.

Cheers
Nik