Greetings!

*** Nik Boehm [2026-08-07 08:25]:
>I noticed that if there is a source file (without a .dep file in .redo/) but a .do file with a matching suffix exists, then targets depending on the source file will be perpetually out of date.  Is this intended behavior or can this be circumvented somehow?

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.

>I have a large collection of binary files that I have downloaded and that will not change.  I initially downloaded them with a script until I switched to a .do file. Since the contents will not change, I would prefer not having to download them again.

I see. I met the same problem in my BASS build system:
http://www.bass.stargrave.org/Build/Distfiles/Cache.html
http://www.git.stargrave.org/?p=bass.git&f=/build/distfiles/dl/default.do
http://www.git.stargrave.org/?p=bass.git&f=/build/distfiles/dl/default.rc
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

>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

>Is the build uuid that is at the top of the .dep file significant or can I write there whatever I please?

It is only used to determine if the target is build during the current
running redo build "session". Can be any valid UUID.

>And is there a way to get the BLAKE3 hash function out of goredo?

Currently no such option.

>In case there is an easier way to fix the issue, I would also be happy to hear that.

None that I can think out more.

-- 
 * Origin: Stargrave's homepage http://www.stargrave.org/