redo=ifchange 1 user commands redo redo-ifchange record and rebuild dependencies redo-ifchange filename(s) REDOFLAGS= --silent --debug --keep-going --verbose redo-ifchange is a dependency redcording and rebuilding utility that is run by a "do" script that is in turn invoked by redo1. redo-ifchange records that the current target (whose "do" script is being run) depends from the dependencies named filenames. The dependency recorded is that the current target should be built if filenames have changed. It also determines, using previously saved dependency information if available, which of the dependencies is itself out of date, and recursively attempts to re-build them, as if by invoking redo1. It delays processing of every dependency that is locked by a concurrent invocation of redo1 or redo-ifchange1. redo-ifchange of necessity recognizes a few of the command-line options supported by redo1, that apply to all redo processes in the tree. However, they are not part of its command-line usage and they are not intended to be used on its command line. Instead, they are passed to it via the REDOFLAGS environment variable which is set up by the ultimate redo1 parent process. This is also how redo-ifchange is informed about where to record dependency information and where the open file descriptors for the jobserver pipe are. Do not, therefore, clear the environment or close arbitrary file descriptors when invoking redo-ifchange. For compatibility, redo-ifchange also understands the MAKEFLAGS, MFLAGS, MAKELEVEL, and __MKLVL__ environment variables. The latter two are used to track recursion depth, by redo and by the GNU and BSD make1 programs. The former two contain command-line options passed down from an ultimake make1 process, similar to REDOFLAGS. Only a few of the options passed via MAKEFLAGS and MFLAGS are acted upon, namely -s, -k, -d, -p, and the undocumented options used to pass along jobserver pipe file descriptor information. All other options used in these environment variables are ignored. If a filename denotes a (character or block) device file, a socket, a FIFO, or a directory, it is considered "changed" based solely upon its last modification timestamp. redo-ifchange does not attempt to open or to read the contents of such files. If filename denotes a symbolic link, it is considered "changed" based upon a combination of its last modification timestamp and the CubeHash hash of its target. To prevent re-calculating the hash value of a symbolic link target repeatedly, redo-ifchange assumes that if a link's symbolic last modification timestamp has not changed, it has not been written to, and therefore the hash of its target cannot have changed. If filename denotes an ordinary file, it is considered "changed" based upon a combination of its last modification timestamp and the CubeHash hash of its contents. To prevent re-calculating the hash value of a file repeatedly, redo-ifchange assumes that if a file's last modification timestamp has not changed, it has not been written to, and therefore the hash of its contents cannot have changed. In both cases, redo-ifchange records the timestamp and hash information in the .redo database. redo-ifchange tries not to hash the same file multiple times. If the same filename is encountered multiple times by a single redo-ifchange process, or if by comparing device and i-node numbers it transpires that redo-ifchange has already hashed the file, it re‐uses the prior hash value without re‐reading the file. Since redo1 (and hence redo-ifchange) performs atomic builds, an already hashed file will not satisfy the device and i-node check if it is re‐built, and will be hashed afresh. Jonathan de Boyne Pollard