Subject: Re: Source files with matching .do file keep targets ood

From: spacefrogg <[email-masked]>
Date: Thu, 20 Aug 2026 17:01:41 +0200

On 2026-08-07 10:56, Sergey Matveev wrote:
> *** Nik Boehm [2026-08-07 10:36]:
>> I agree that if there is a file called a.ext.do then it would make 
>> sense.  With a default.ext.do file the usefulness is more debatable.
> 
> default*.do should not be any way different from non-default .do files.
> It is just like "wildcard" .do.
> 
>> I would tend to say that there shouldn't be a reason to consider 
>> targets that depend on the source file a.ext to always be OOD.
> 
> Either I am missing something, or there is misuse of terms.
> "source file" is a file, which is not generated by redo, which lacks 
> any
> corresponding .do file. For example having default.do means that there
> can be no source files in the directory with it (or in subdirectories).
> Either the target is generated, or it is "source file". Having foo.ext
> and default.ext.do means that foo.ext is not treated like a source 
> file,
> but a valid target which redo must generate if it is OOD. If it lacks
> dependency (.dep file) information, then redo treats it like "target 
> has
> not been done", it is non existent, so must be rebuilt.
> 
>> Surely the last line has to stay since otherwise every source file 
>> would always be OOD.  I don’t know if it makes sense to keep the 
>> second line with its current behavior.  What do you think?  I realize 
>> that it can be surprising that a target is not redone even though it 
>> has a .do file simply because it’s recorded as a source file.  But 
>> that is partly a user error.  Would it be possible to have a file 
>> depending on a.ext not be OOD?
> 
> If there is default.ext.do and a.ext was not build under redo (so it
> misses the corresponding .redo/a.ext.dep) -- then it will be OOD, no
> other choices.

I think, I have argued that before and I still think this behaviour is 
very wrong.

As we all agree, redo is a stateful build system. So, what are the 
useful states a target <A> can be in?
unknown: redo does know about <A>, ie. has no record of it
source: redo has no record (or is recorded as a "source" to keep extra 
data to determine OOD) of <A> but <A> exists. So, it is a source.
target: redo has a record of <A> and <A> either does not exist or <A>'s 
state is consistent with the record
locked: redo has a record of <A> and <A> exists but is inconsistent with 
the record

As we can see, for <A> itself, OOD is not a factor. OOD only comes into 
play in the relation between <A> and its dependencies.  All targets have 
at least one dependency, their producing .do file.

Now to the transitions between the states for target <A>:

unknown -> source: redo is called on <A>, has no prior knowledge about 
it, and <A> exists.
unknown -> target: redo is called on <A>, has no prior knowledge about 
it, <A> doesn't exist and a .do file to produce <A> can be found.
source -> unknown: redo is called on some <B> which used to depend on 
<A> but no longer does. So redo forgets about <A> entirely.
target -> locked: redo is called on <A>, <A> exists and does not match 
redo's record of it.
locked -> target: redo is called on <A>, <A> no longer exists, which 
resolves the mismatch with the record and <A> is rebuilt.

Now, where I think goredo currently takes the wrong turn:
It should not consider <A> OOD just because there is some .do file to 
produce <A>. If <A> exists before redo has a record of it, it should 
just treat <A> as a source and be happy. Obviously, redo will never 
rebuild <A>. So, if a user mistakenly has removed the .redo database, 
all current targets turn into sources and redo won't rebuild anything 
anymore. But hey, so is life. Complex project just have cleanup rules 
anyhow which the user can call and start over again.

Expecting that a directory that contains a default.do file must 
otherwise be empty (because all other files, including in 
subdirectories, would be in conflict now) is completely useless.  
default.do files are supposed to be catchall rules that make sure that 
build instructions never escape a subtree, because they always terminate 
at the nearest default.do.

I hope my ramblings made any sense.

–Michael