public inbox for goredo-devel@lists.cypherpunks.ru
Atom feed
From: goredo <spacefrogg-goredo@spacefrogg•net>
To: goredo-devel@lists.cypherpunks.ru
Subject: Re: Multiple calls to redo-* for same target results in multiple .rec entries
Date: Thu, 4 Nov 2021 15:35:15 +0000 (UTC)	[thread overview]
Message-ID: <6e5c1f7a-3ce7-4ecb-8d05-5d1b6f787928@spacefrogg.net> (raw)
In-Reply-To: <YX5R/aRdOGSkyvTZ@stargrave.org>

Hi,

For several days, you had me convinced that dependency recording could be kept that simple, but now I've triggered a bug.

Write a default.do.do and create a foo/default.do from it. Try again and redo fails with
```
main.go:484: foo/default.do: Size missing
```

redo implicitly records an ifcreate dependency on default.do (as it was missing in foo/ the first time).

This can, of course, be remedied by not recording .do files as ifcreate dependencies that are the current target. Removing the ifcreate dependency from the rec file fixes the issue.

Still, this had me thinking what it means to have an ifcreate and ifchange dependency on a file, whether the order matters or should matter, and how other redo implementations behave in that case. Especially because redo provides no way to check or remove prior decisions. I'm leaning towards an approach that either records exactly one dependency per target, or where only the last dependency to a specific target is considered. (I.e. last writer wins semantics)

What do you think? goredo should treat dependencies the same as the other implementations, shouldn't it?

Regards,
–Michael

  reply	other threads:[~2021-11-04 15:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 17:18 Multiple calls to redo-* for same target results in multiple .rec entries goredo
2021-10-31  8:21 ` Sergey Matveev
2021-11-04 15:35   ` goredo [this message]
2021-11-09  9:13     ` Sergey Matveev
2021-11-09 13:43       ` goredo
2021-11-10 10:47         ` Sergey Matveev
2021-11-10 12:22         ` redo-stamp Sergey Matveev