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'.
1.4 KiB
NAME
redo-always - mark the current target as always needing to be rebuilt
SYNOPSIS
redo-always
DESCRIPTION
Normally redo-always is run from a .do file that has been
executed by redo(1). See redo(1) for more details.
redo-always takes no parameters. It simply adds an
'impossible' dependency to the current target, which
ensures that the target will always be rebuilt if anyone
runs redo-ifchange targetname.
Because of the way redo works, redo-ifchange targetname
will only rebuild targetname once per session. So if
multiple targets depend on targetname and targetname
has called redo-always, only the first target will cause it
to be rebuilt. If the build cycle completes and a new one
begins, it will be rebuilt exactly one more time.
Normally, any target that depends (directly or indirectly)
on a sub-target that has called redo-always will also
always need to rebuild, since one of its dependencies will
always be out of date. To avoid this problem, redo-always is
usually used along with redo-stamp(1).
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-ifchange(1), redo-stamp(1)