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.
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
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.