f6fe00db5c
It's time to start preparing for a version of redo that doesn't work unless we build it first (because it will rely on C modules, and eventually be rewritten in C altogether). To get rolling, remove the old-style symlinks to the main programs, and rename those programs from redo-*.py to redo/cmd_*.py. We'll also move all library functions into the redo/ dir, which is a more python-style naming convention. Previously, install.do was generating wrappers for installing in /usr/bin, which extend sys.path and then import+run the right file. This made "installed" redo work quite differently from running redo inside its source tree. Instead, let's always generate the wrappers in bin/, and not make anything executable except those wrappers. Since we're generating wrappers anyway, let's actually auto-detect the right version of python for the running system; distros can't seem to agree on what to call their python2 binaries (sigh). We'll fill in the right #! shebang lines. Since we're doing that, we can stop using /usr/bin/env, which will a) make things slightly faster, and b) let us use "python -S", which tells python not to load a bunch of extra crap we're not using, thus improving startup times. Annoyingly, we now have to build redo using minimal/do, then run the tests using bin/redo. To make this less annoying, we add a toplevel ./do script that knows the right steps, and a Makefile (whee!) for people who are used to typing 'make' and 'make test' and 'make clean'.
2.6 KiB
NAME
redo-ifchange - rebuild target files when source files have changed
SYNOPSIS
redo-ifchange [targets...]
DESCRIPTION
Normally redo-ifchange is run from a .do file that has been
executed by redo(1). See redo(1) for more details.
redo-ifchange doesn't take any command line options other
than a list of targets. To provide command line options,
you need to run redo instead.
redo-ifchange performs the following steps:
-
it creates a dependency on the given targets. If any of those targets change in the future, the current target (the one calling redo-ifchange) will marked as needing to be rebuilt.
-
for any target that is out of date, it calls the equivalent of
redo target. -
for any target that is locked (because some other instance of
redoorredo-ifchangeis already building it), it waits until the lock is released.
redo-ifchange returns only after all the given targets are known to be up to date.
TIP 1
You don't have to run redo-ifchange before generating your target; you can generate your target first, then declare its dependencies. For example, as part of compiling a .c file, gcc learns the list of .h files it depends on. You can pass this information along to redo-ifchange, so if any of those headers are changed or deleted, your .c file will be rebuilt:
redo-ifchange $2.c
gcc -o $3 -c $2.c \
-MMD -MF $2.deps
read DEPS <$2.deps
redo-ifchange ${DEPS#*:}
This is much less confusing than the equivalent
autodependency mechanism in make(1), because make
requires that you declare all your dependencies before
running the target build commands.
TIP 2
Try to list as many dependencies as possible in a single call to redo-ifchange. Every time you run redo-ifchange, the shell has to fork+exec it, which takes time. Plus redo can only parallelize your build if you give it multiple targets to build at once. It's fine to have a couple of separate redo-ifchange invocations for a particular target when necessary (as in TIP 1 above), but try to keep it to a minimum. For example here's a trick for generating a list of targets, but redo-ifchanging them all at once:
for d in *.c; do
echo ${d%.c}.o
done |
xargs redo-ifchange
REDO
Part of the redo(1) suite.
CREDITS
The original concept for redo was created by D. J.
Bernstein and documented on his web site
(http://cr.yp.to/redo.html). This independent implementation
was created by Avery Pennarun and you can find its source
code at http://github.com/apenwarr/redo.
SEE ALSO
redo(1), redo-ifcreate(1), redo-always(1), redo-stamp(1)