REDO-IFCHANGE(1)

NAME
redo-ifchange - rebuild target files when source files have changed

SYNOPSIS
redo-ifchange target [target]...

DESCRIPTION
redo(1) is a tool for building files and for rebuilding them if any of their dependencies have changed. redo-ifchange, when invoked from a dofile, adds dependencies of the current redo(1) target on all files given as arguments, (re)builds those files if necessary and rebuilds the current target if the files given as arguments have changed since the last build.

Internally redo-ifchange uses stat(1) and md5sum(1) or openssl(1) or md5(1) to determine if a file is out of date. If the ctime of a file did not change since the last build, redo-ifchange considers the file up to date. If the checksum of a file did not change, redo-ifchange updates the stored ctime and considers the file up to date. Otherwise, redo-ifchange considers the file out of date.

When redo(1) is invoked with the -j or --jobs option and an integer argument greater than 1, redo-ifchange(1) can build multiple targets in parallel. The integer argument specifies the maximum number of targets that redo-ifchange(1) is allowed to build in parallel.

redo-ifchange(1) processes started as a result of the same redo(1) invocation share knowledge of a temporary “canary” path. If any redo-ifchange(1) process exits with a status code indicating error or receives a SIGINT signal (interrupt from keyboard), it creates a file at the “canary” path. When redo-ifchange(1) notices such a “canary” file, it exits as soon as possible with a status code indicating error.

redo-ifchange(1) will warn if a non-top-level build rule does not write anything to a target. Depending on “build rules” that consist entirely of side effects is usually a mistake.

EXAMPLES

Consider the following four files all.do, b.do, c and d:

all.do
    #!/bin/sh
    redo-ifchange b

b.do
    #!/bin/sh
    redo-ifchange c d
    date +%s

c
    foo

d
    bar

Invoking redo(1) in a directory with these files will build a file named b containing a timestamp. The next time redo(1) is invoked, it will only rebuild b if the contents of b, c or d have changed since the last build. This can be verified by invoking redo(1), repeatedly and examining the timestamp in b, after each invocation, then changing the contents of b, c or d and invoking redo(1) again.

HISTORY
redo-ifchange was designed by D. J. Bernstein and implemented by Nils Dagsson Moskopp.

AUTHOR
redo-ifchange
    and this man page were written by Nils Dagsson Moskopp.

COPYRIGHT
Copyright © 2014-2016 Nils Dagsson Moskopp. License AGPLv3+: GNU Affero GPL version 3 or later <http://www.gnu.org/licenses/agpl-3.0.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

SEE ALSO
redo(1), redo-always(1), redo-dot(1), redo-ifcreate(1), redo-ood(1), redo-sources(1), redo-stamp(1), redo-targets(1), signal(7)

BUGS
redo-ifchange erroneously considers target files always out of date if their name contains a tab or a newline character.

On a computer with a stat(1) implementation that does not accept the -c%Y option, redo-ifchange considers target files to be always out of date.

When building in parallel and sending a SIGINT signal (interrupt from keyboard) to a redo-ifchange(1) process, other redo-ifchange(1) processes started from the same redo(1) invocation might not immediately notice the existence of the “canary“ file and linger for a short time.