public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: Nik Boehm <mail@jnboehm•com>
To: goredo-devel@lists.stargrave.org
Subject: Re: Source files with matching .do file keep targets ood
Date: Fri, 7 Aug 2026 10:36:56 +0200	[thread overview]
Message-ID: <8C0DB0F5-7F85-4BC1-A389-DE19D3C32400@jnboehm.com> (raw)
In-Reply-To: <anWRa-rDjhsI0Pj2@stargrave.org>

Thanks for the quick answer!

> On 7 Aug 2026, at 10:03, Sergey Matveev <stargrave@stargrave•org> 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!



  reply	other threads:[~2026-08-07  8:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07  6:25 Source files with matching .do file keep targets ood Nik Boehm
2026-08-07  8:03 ` Sergey Matveev
2026-08-07  8:36   ` Nik Boehm [this message]
2026-08-07  8:56     ` Sergey Matveev
2026-08-20 15:01       ` spacefrogg