public inbox for goredo-devel@lists.stargrave.org
Atom feed
From: spacefrogg <spacefrogg-goredo@spacefrogg•net>
To: goredo-devel@lists.stargrave.org
Subject: Re: Source files with matching .do file keep targets ood
Date: Thu, 20 Aug 2026 17:01:41 +0200 [thread overview]
Message-ID: <4846b4ed2ecef310e4be49093d72654b@spacefrogg.net> (raw)
In-Reply-To: <anWd0jW8DGrMI82i@stargrave.org>
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
prev parent reply other threads:[~2026-08-20 15:26 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
2026-08-07 8:56 ` Sergey Matveev
2026-08-20 15:01 ` spacefrogg [this message]