redo-touch?

17 views
Skip to first unread message

Buck Evan

unread,
Mar 9, 2023, 4:23:33 PM3/9/23
to redo
First, thanks for the great tool :)

I've been using it and it's quite pleasant, but there's a few things that I want to do that I haven't figured out how.

1. force a target valid -- After I'm done with my "temporary override" of a target, I'd like to put it back how I found it without re-running all its (very slow) dependencies. In `make` there's a `-t` option for this purpose which works nicely. I've tried several things to no avail. I've even gone so far as to move a valid file away (so its inode and mtime, everything are preserved) then (after other work) moving it back, but redo refuses to acknowlege that this is the (once again) the clean file it was expecting. Am I missing something?

2. a "dry-run" -- In make, I can have a look at what's about to happen and even debug or fix dependency issues before the fact with the `-n, --just-print, --dry-run, --recon` option. Is there an equivalent in redo? `redo -d` is pretty close, but it also executes the commands.

Secondarily, if these are not supported features, would you be receptive to assistance in adding them?

spacefro...@meterriblecrew.net

unread,
Mar 13, 2023, 9:58:05 AM3/13/23
to redo...@googlegroups.com
Hi,

there is no built-in functionality for 1). goredo has something, but it is not "standard". Such a function always has high misuse potential, especially in redo, because the distinction between user API and build API is not very pronounced. It is only really useful for very expensive targets otherwise you should always prefer a clean rebuild. Lastly, it is unnecessary with redo. My solution is to do the following:

I use default.valuable.do for my expensive target. By default this triggers default.expensive.do, which is the actual expensive target and does all the work. On the side default.valuable.do looks for default.stay-fixed. If it exists, it is used to created default.valuable, circumventing default.expensive.do. So instead of modifying default.expensive directly, you copy/modify default.stay-fixed. Once you remove it, the normal build chain is triggered and since default.expensive was never modified in the first place, no rebuild is necessary. All names used here were obviously completely fabricated.

As a modification, I also use this on complete directory trees in which I can make a shadow tree of prebuilt or modified targets. The respective .do files look for the existence of their target in the shadow tree and collapse target creation to copy.

Regarding 2)

Short answer: Impossible with arbitrary shell scripts.

Long answer: There are numerous stackoverflow answers to why it is impossible. Again, simulating a shell script (or any scripting language) is, in general, theoretically impossible. So, don't search for a solution. Simple example, consider the following shell code in the assumed file a.do:

while read -r f ; do
  redo-ifchange "$f"
done < data.file

It is impossible to infer the a.do's dependencies without actually executing it. Remember that data.file could, as well, be arbitrary shell code, generating the dara. Restricting redo to printing a.do's content would give you meaningless results.

You can use redo-sources and redo-targets to get an impression of your code base after you have executed enough targets and redo was able to build a database.

The solution to that is, that it is now your responsibility, as the one who writes the .do files, to split your code (if possible) into sections that determine dependencies and sections that generate output, and to build in a trigger to disable output generation. So, while it's impossible with arbitrary shell scripts, redo does not restrict you to create a toolchain that indeed supports dry-run. redo just won't hand you a golden gun for that, it only does dependency management.

Kind regards,
–Michael
Reply all
Reply to author
Forward
0 new messages