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

From: Nik Boehm <[email-masked]>
Date: Fri, 7 Aug 2026 10:36:56 +0200

Thanks for the quick answer!

> On 7 Aug 2026, at 10:03, Sergey Matveev <[email-masked]> wrote:
> 
> Do I clearly understand, that you have got "foo" file, and a "foo.do"
> appeared, which leads to "foo" being an out-of-date? Yes, that is
> intended, because "foo" is missing the "record" in .redo/ directory, it
> was not built under redo control and has no information to determine is
> it OOD. For goredo it is safer to rebuild it.

Almost, I have a file a.ext and default.ext.do, but I still get the warning.  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. 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.

Right now the behavior is as follows IIUC:
- a.ext.do warning/ood
- default.ext.do warning/ood
- default.do nothing

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?

> I see. I met the same problem in my BASS build system:
> The .do checks if cache/$target exists and hardlinks it
> (ln cache/$target $3). Actually target is rebuilt, but at least it just
> finishes with non expensive ln call. Same is done with prebuilt packages
> (which should not be rebuild, just used as is):
> http://www.git.stargrave.org/?p=bass.git&f=/build/skel/common.rc

Good to see that you have faced a similar problem before.

> 
>> Alternatively, I could also write a .dep file for each of the binary files manually to get goredo to treat them as not ood.  Is there anything I need to be aware of for that?  My idea is to write a .rec file and then use redo-depfix, will that work?
> 
> Yes, it will. Hash will be optional in that case.
> 
>    $ mkdir .redo
>    $ {
>        echo Build: 00000000-0000-0000-0000-000000000000
>        redo-inode foo | perl -npe 'print "Type: ifchange\n" if /^Target/'
>    } >.redo/foo.rec
>    $ redo-depfix foo

Why is the hash optional in those cases?

>> And is there a way to get the BLAKE3 hash function out of goredo?
> 
> Currently no such option.

Okay, it’s easy enough to get a reference implementation, so no problem.

Thanks for the detailed answer to my points!