public inbox for goredo-devel@lists.stargrave.org 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