public inbox for goredo-devel@lists.cypherpunks.su
Atom feed
* Unexpected behavior in redoing target with missing .redo info
@ 2025-12-05 18:30 Niklas Böhm
2025-12-05 19:26 ` goredo
2025-12-12 15:38 ` Sergey Matveev
0 siblings, 2 replies; 4+ messages in thread
From: Niklas Böhm @ 2025-12-05 18:30 UTC (permalink / raw)
To: goredo-devel
Hi,
I observed the following problem with using redo and would like to
challenge the current behavior of the program.
I have the following file with one line, 1.do:
echo hi > $3
When I now call `redo 1`, everything works as expected. But in case the
file `1` already exists (or you remove the folder `.redo/`), then the
call to `redo 1` throws the following error:
err 1 (0.001s): $1 was explicitly touched
I think that this is a bug (most probably related to run.go l.674 or so)
and the behavior should be to either (a) detect it as a source file and
not redo it (the behavior if the file `1.do` did not exist) or (b) redo
the target properly. I strongly prefer option (a), as we should not
mess with a file that we do not know the origin of.
At the very least, the error message about $1 being touched (which is
not happening in this scenario) is quite misleading (I actually thought
that I misunderstood something about this). There might be a logic
error with regards to when the presence of a source file if checked and
the presence of a .do file.
Let me know what you think! And thanks for goredo :)
Greetings
Nik
^ permalink raw reply [flat|nested] 4+ messages in thread
* Unexpected behavior in redoing target with missing .redo info
2025-12-05 18:30 Unexpected behavior in redoing target with missing .redo info Niklas Böhm
@ 2025-12-05 19:26 ` goredo
2025-12-12 15:38 ` Sergey Matveev
1 sibling, 0 replies; 4+ messages in thread
From: goredo @ 2025-12-05 19:26 UTC (permalink / raw)
To: goredo-devel
Yes, that is a bug.
You can observe the correct behaviour when you change `1.do` to `default.do`, which is:
- after deleting `.redo/` `redo 1` prints nothing anymore, because it treats the file as a source file. You can verify by setting REDO_DEBUG=1.
Best regards,
–Michael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Unexpected behavior in redoing target with missing .redo info
2025-12-05 18:30 Unexpected behavior in redoing target with missing .redo info Niklas Böhm
2025-12-05 19:26 ` goredo
@ 2025-12-12 15:38 ` Sergey Matveev
2025-12-16 13:45 ` Sergey Matveev
1 sibling, 1 reply; 4+ messages in thread
From: Sergey Matveev @ 2025-12-12 15:38 UTC (permalink / raw)
To: goredo-devel
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
Greetings!
*** Niklas Böhm [2025-12-05 19:30]:
>file `1` already exists (or you remove the folder `.redo/`), then the call
>to `redo 1` throws the following error:
>
>err 1 (0.001s): $1 was explicitly touched
That message is misleading indeed. Fixed in 2.7.0 release. Now it will
print "already existing".
>I think that this is a bug (most probably related to run.go l.674 or so) and
>the behavior should be to either (a) detect it as a source file and not redo
>it (the behavior if the file `1.do` did not exist) or (b) redo the target
>properly. I strongly prefer option (a), as we should not mess with a file
>that we do not know the origin of.
I completely agree that (b) is not acceptable: we must not touch files
which we do not created. But I doubt (a), treating it like a source
file, is a good option too: how we differentiate and understand was it
accidentally created or user does not notice its existence with the
corresponding .do?
*** spacefrogg-goredo [2025-12-05 20:26]:
>Yes, that is a bug.
>You can observe the correct behaviour when you change `1.do` to `default.do`, which is:
>- after deleting `.redo/` `redo 1` prints nothing anymore, because it treats the file as a source file. You can verify by setting REDO_DEBUG=1.
That is very good point! Of course existence of default.do-s should be
treated like a presence of the .do. goredo checked if source file is a
source just by checking the nearby $1.do existence.
I think that "source file" is a file which does not have build
instructions (corresponding .do file). So we should use the same logic
of do-files searching for the consistency of the behaviour. If we find a
.do file, the presence of already existing target and lack of its
information in .redo-state, then we should warn user about already
existing target. But, just like in the case of "externally modified"
one, continue the redo process without raising an error, not touching
that target's file.
I brought those changes (proper check of .do existence and a
non-misleading warning message) in the 2.7.0 release. But that also
leads to inability to have multiple default.*.do together with
default.do. As every file, including do-file itself, can be build by
redo itself, it has to be checked the same way as every other ones.
Having default.do will lead to treating it like a do-file for the
default.*.do nearby. But that should be the expected behaviour.
Otherwise how can be distinguish autogenerated do-files from
mistakenly left.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Unexpected behavior in redoing target with missing .redo info
2025-12-12 15:38 ` Sergey Matveev
@ 2025-12-16 13:45 ` Sergey Matveev
0 siblings, 0 replies; 4+ messages in thread
From: Sergey Matveev @ 2025-12-16 13:45 UTC (permalink / raw)
To: goredo-devel
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Greetings!
*** Sergey Matveev [2025-12-12 18:38]:
>I think that "source file" is a file which does not have build
>instructions (corresponding .do file). So we should use the same logic
>of do-files searching for the consistency of the behaviour.
As I mentioned previously, that also means that every file nearby the
default.do will be treated like a non-source one. In theory every
default.XXX.do nearby must be recreated from default.do, in that case.
But I think that this is not convenient for most purposes. XXX.do and
default.YYY.do must be treated like a higher precedence build rules.
In goredo 2.7.0 they behave that way as before -- nothing changed. But
unfortunately they (those .do-s) were always treated like out-of-date
targets. In 2.8.0 I fixed that: if file is not a source file (it has
.do, possibly default.do), but it has .do suffix in filename, then
treat it like a source one.
I am not fully confident about those changes, but seems they break
neither any previous expected behaviour, nor always-OOD some targets
like in 2.7.0.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-12-16 13:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-12-05 18:30 Unexpected behavior in redoing target with missing .redo info Niklas Böhm
2025-12-05 19:26 ` goredo
2025-12-12 15:38 ` Sergey Matveev
2025-12-16 13:45 ` Sergey Matveev