Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Autogenerated man pages for redo-0.10

  • Loading branch information...
commit c1951855b2bb727bf64a1026ff80978920b901bc 1 parent 03991ca
@apenwarr authored
View
70 redo-always.1
@@ -1,46 +1,40 @@
-.TH redo-always 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-ALWAYS 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
-redo-always - mark the current target as always needing to be
-rebuilt
+redo-always - mark the current target as always needing to be rebuilt
.SH SYNOPSIS
-.PP
redo-always
.SH DESCRIPTION
-.PP
-Normally redo-always is run from a \.do file that has been executed
-by \f[B]redo\f[](1)\. See \f[B]redo\f[](1) for more details\.
-.PP
-redo-always takes no parameters\. It simply adds an
-\[aq]impossible\[aq] dependency to the current target, which
-ensures that the target will always be rebuilt if anyone runs
-\f[B]redo-ifchange\ targetname\f[]\.
-.PP
-Because of the way redo works, \f[B]redo-ifchange\ targetname\f[]
-will only rebuild \f[B]targetname\f[] once per session\. So if
-multiple targets depend on \f[I]targetname\f[] and
-\f[I]targetname\f[] 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\.
-.PP
-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
-\f[B]redo-stamp\f[](1)\.
+Normally redo-always is run from a .do file that has been
+executed by \fBredo\fR(1). See \fBredo\fR(1) for more details.
+.PP
+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 \fBredo-ifchange targetname\fR.
+.PP
+Because of the way redo works, \fBredo-ifchange targetname\fR
+will only rebuild \fBtargetname\fR once per session. So if
+multiple targets depend on \fItargetname\fR and \fItargetname\fR
+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.
+.PP
+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 \fBredo-stamp\fR(1).
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-ifcreate\f[](1),
-\f[B]redo-ifchange\f[](1), \f[B]redo-stamp\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-ifcreate\fR(1), \fBredo-ifchange\fR(1), \fBredo-stamp\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
127 redo-ifchange.1
@@ -1,69 +1,88 @@
-.TH redo-ifchange 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-IFCHANGE 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo-ifchange - rebuild target files when source files have changed
.SH SYNOPSIS
-.PP
-redo-ifchange [targets\.\.\.]
+redo-ifchange [targets...]
.SH DESCRIPTION
+Normally redo-ifchange is run from a .do file that has been
+executed by \fBredo\fR(1). See \fBredo\fR(1) for more details.
.PP
-Normally redo-ifchange is run from a \.do file that has been
-executed by \f[B]redo\f[](1)\. See \f[B]redo\f[](1) for more
-details\.
-.PP
-redo-ifchange doesn\[aq]t take any command line options other than
-a list of \f[I]targets\f[]\. To provide command line options, you
-need to run \f[B]redo\f[] instead\.
+redo-ifchange doesn't take any command line options other
+than a list of \fItargets\fR. To provide command line options,
+you need to run \fBredo\fR instead.
.PP
redo-ifchange performs the following steps:
-.IP \[bu] 2
-it creates a dependency on the given \f[I]targets\f[]\. If any of
-those targets change in the future, the current target (the one
-calling redo-ifchange) will marked as needing to be rebuilt\.
-.IP \[bu] 2
-for any \f[I]target\f[] that is out of date, it calls the
-equivalent of \f[B]redo\ target\f[]\.
-.IP \[bu] 2
-for any \f[I]target\f[] that is locked (because some other instance
-of \f[B]redo\f[] or \f[B]redo-ifchange\f[] is already building it),
-it waits until the lock is released\.
+.IP " \[bu] " 3
+.IP " " 3
+it creates a dependency on the given \fItargets\fR. If any
+of those targets change in the future, the current target
+(the one calling redo-ifchange) will marked as needing to
+be rebuilt.
+.IP " \[bu] " 3
+.IP " " 3
+for any \fItarget\fR that is out of date, it calls the
+equivalent of \fBredo target\fR.
+.IP " \[bu] " 3
+.IP " " 3
+for any \fItarget\fR that is locked (because some other
+instance of \fBredo\fR or \fBredo-ifchange\fR is already building
+it), it waits until the lock is released.
.PP
-redo-ifchange returns only after all the given \f[I]targets\f[] are
-known to be up to date\.
-.SH TIP
+redo-ifchange returns only after all the given
+\fItargets\fR are known to be up to date.
+.SH "TIP 1"
+You don't have to run redo-ifchange \fIbefore\fR 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:
+.RS +4n
+.nf
.PP
-You don\[aq]t have to run redo-ifchange \f[I]before\f[] 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#*:}
+.fi
+.RE
.PP
-\f[CR]
- \ \ \ \ redo-ifchange\ $1$2
- \ \ \ \ gcc\ -o\ $3\ -c\ $1$2\ \\
- \ \ \ \ \ \ \ \ -MMD\ -MF\ $1\.deps\ -MT\ DELETE_ME
- \ \ \ \ redo-ifchange\ $(sed\ -e\ \[aq]s,^DELETE_ME:,,\[aq]\ \\
- \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ -e\ \[aq]s,\\\\,,\[aq]\ $1\.deps)
-\f[]
+This is much less confusing than the equivalent
+autodependency mechanism in \fBmake\fR(1), because make
+requires that you declare all your dependencies before
+running the target build commands.
+.SH "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:
+.RS +4n
+.nf
.PP
-This is much less confusing than the equivalent autodependency
-mechanism in \f[B]make\f[](1), because make requires that you
-declare all your dependencies before running the target build
-commands\.
+for d in *.c; do
+ echo ${d%.c}.o
+done |
+xargs redo-ifchange
+.fi
+.RE
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-ifcreate\f[](1),
-\f[B]redo-always\f[](1), \f[B]redo-stamp\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-ifcreate\fR(1), \fBredo-always\fR(1), \fBredo-stamp\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
54 redo-ifcreate.1
@@ -1,40 +1,34 @@
-.TH redo-ifcreate 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-IFCREATE 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
-redo-ifcreate - rebuild the current target if source files are
-created
+redo-ifcreate - rebuild the current target if source files are created
.SH SYNOPSIS
-.PP
-redo-ifcreate [sources\.\.\.]
+redo-ifcreate [sources...]
.SH DESCRIPTION
+Normally redo-ifcreate is run from a .do file that has been
+executed by \fBredo\fR(1). See \fBredo\fR(1) for more details.
.PP
-Normally redo-ifcreate is run from a \.do file that has been
-executed by \f[B]redo\f[](1)\. See \f[B]redo\f[](1) for more
-details\.
-.PP
-redo-ifcreate takes a list of nonexistent files (\f[I]sources\f[])
-and adds them as dependencies to the current target (the one
-calling redo-ifcreate)\. If any of those files are created in the
-future, the target will be marked as needing to be rebuilt\.
+redo-ifcreate takes a list of nonexistent files (\fIsources\fR)
+and adds them as dependencies to the current target (the
+one calling redo-ifcreate). If any of those files are
+created in the future, the target will be marked as needing
+to be rebuilt.
.PP
-If one of the given files exists at the time redo-ifcreate is
-called, it will return a nonzero exit code\.
+If one of the given files exists at the time redo-ifcreate
+is called, it will return a nonzero exit code.
.PP
-If you want to declare dependencies on files that already exist,
-use \f[B]redo-ifchange\f[](1) instead\.
+If you want to declare dependencies on files that already
+exist, use \fBredo-ifchange\fR(1) instead.
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-ifchange\f[](1),
-\f[B]redo-always\f[](1), \f[B]redo-stamp\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-ifchange\fR(1), \fBredo-always\fR(1), \fBredo-stamp\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
77 redo-ood.1
@@ -1,49 +1,46 @@
-.TH redo-ood 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-OOD 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo-ood - print the list of out-of-date redo targets
.SH SYNOPSIS
-.PP
redo-ood
.SH DESCRIPTION
-.PP
-redo-ood prints a list of all redo \f[I]target\f[] files that
-exist, but are out of date\.
-.PP
-Files that no longer exist might not be targets anymore; you\[aq]ll
-have to redo them for them to end up back in this list\. (For
-example, if you built a file and then removed the file and its \.do
-file, you wouldn\[aq]t want it to show up in this list\.)
-.PP
-If a \.do script does not produce an output file (eg\. all\.do,
-clean\.do), it also does not show up in this list\.
-.PP
-Each filename is on a separate line\. The filenames are not
-guaranteed to be in any particular order\.
-.PP
-All filenames are printed relative the current directory\. The list
-is not filtered in any way; it contains \f[I]all\f[] the target
-filenames from the entire project\. Remember that the redo database
-may span more than just your project, so you might need to filter
-the list before using it\. (A useful heuristic might be to remove
-any line starting with \[aq]\.\./\[aq] since it often refers to a
-target you don\[aq]t care about\.)
-.PP
-If you want a list of all targets, not just out-of-date ones, use
-\f[B]redo-targets\f[](1)\.
+redo-ood prints a list of all redo \fItarget\fR files that
+exist, but are out of date.
+.PP
+Files that no longer exist might not be targets anymore;
+you'll have to redo them for them to end up back in this
+list. (For example, if you built a file and then removed
+the file and its .do file, you wouldn't want it to show up
+in this list.)
+.PP
+If a .do script does not produce an output file (eg.
+all.do, clean.do), it also does not show up in this list.
+.PP
+Each filename is on a separate line. The filenames are not
+guaranteed to be in any particular order.
+.PP
+All filenames are printed relative the current directory.
+The list is not filtered in any way; it contains \fIall\fR the
+target filenames from the entire project. Remember that
+the redo database may span more than just your project, so
+you might need to filter the list before using it. (A
+useful heuristic might be to remove any line starting with
+'../' since it often refers to a target you don't care
+about.)
+.PP
+If you want a list of all targets, not just out-of-date
+ones, use \fBredo-targets\fR(1).
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-targets\f[](1),
-\f[B]redo-sources\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-targets\fR(1), \fBredo-sources\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
54 redo-sources.1
@@ -1,43 +1,39 @@
-.TH redo-sources 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-SOURCES 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo-sources - print the list of all known redo sources
.SH SYNOPSIS
-.PP
redo-sources
.SH DESCRIPTION
+redo-sources prints a list of all redo \fIsource\fR files that
+still exist.
.PP
-redo-sources prints a list of all redo \f[I]source\f[] files that
-still exist\.
-.PP
-A source file is any file that has been listed as a dependency
-(using \f[B]redo-ifchange\f[](1) or \f[B]redo-ifcreate\f[](1)) but
-is not itself a target\. A target is a file that \f[B]redo\f[](1)
-can build using a \.do script\.
+A source file is any file that has been listed as a
+dependency (using \fBredo-ifchange\fR(1) or \fBredo-ifcreate\fR(1))
+but is not itself a target. A target is a file that
+\fBredo\fR(1) can build using a .do script.
.PP
-Each filename is on a separate line\. The filenames are not
-guaranteed to be in any particular order\.
+Each filename is on a separate line. The filenames are not
+guaranteed to be in any particular order.
.PP
-All filenames are printed relative the current directory\. The list
-is not filtered in any way; it contains \f[I]all\f[] the source
-filenames from the entire project\. Remember that the redo database
-may span more than just your project, so you might need to filter
-the list before using it\.
+All filenames are printed relative the current directory.
+The list is not filtered in any way; it contains \fIall\fR the
+source filenames from the entire project. Remember that
+the redo database may span more than just your project, so
+you might need to filter the list before using it.
.PP
If you want a list of targets instead of sources, use
-\f[B]redo-targets\f[](1) or \f[B]redo-ood\f[](1)\.
+\fBredo-targets\fR(1) or \fBredo-ood\fR(1).
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-targets\f[](1), \f[B]redo-ood\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-targets\fR(1), \fBredo-ood\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
189 redo-stamp.1
@@ -1,116 +1,117 @@
-.TH redo-stamp 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-STAMP 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo-stamp - detect if the current target has meaningfully changed
.SH SYNOPSIS
-.PP
-redo-stamp <$3
+redo-stamp <\\$3
.SH DESCRIPTION
-.PP
-Normally, when \f[B]redo\f[](1) builds a target T, all the other
-targets that depend on T are marked as out of date\. Even if the
-rebuilt T is identical to the old one, all its dependents need to
-be rebuilt\.
-.PP
-By calling redo-stamp from your \.do script, you can tell
-\f[B]redo\f[] that even though the current target is building, its
-output may turn out to be unchanged\. If it hasn\[aq]t,
-\f[B]redo\f[] may then be able to avoid building other targets that
-depend on this target\.
-.PP
-redo-stamp marks the current target as changed or unchanged by
-comparing its stdin to the input that was provided last time
-redo-stamp was called for this target\.
-.PP
-The stamp data can be anything you want\. Some possibilities are:
-.IP \[bu] 2
+Normally, when \fBredo\fR(1) builds a target T, all the other
+targets that depend on T are marked as out of date. Even
+if the rebuilt T is identical to the old one, all its
+dependents need to be rebuilt.
+.PP
+By calling redo-stamp from your .do script, you can tell
+\fBredo\fR that even though the current target is building, its
+output may turn out to be unchanged. If it hasn't, \fBredo\fR
+may then be able to avoid building other targets that
+depend on this target.
+.PP
+redo-stamp marks the current target as changed or unchanged
+by comparing its stdin to the input that was provided last
+time redo-stamp was called for this target.
+.PP
+The stamp data can be anything you want. Some possibilities
+are:
+.IP " \[bu] " 3
+.IP " " 3
the actual target file contents:
-.RS 2
-.PP
-\f[CR]
- redo-stamp\ <\\$3
-\f[]
+.RS +4n
+.nf
+.IP " " 3
+redo-stamp <\\$3
+.fi
.RE
-.IP \[bu] 2
+.IP " \[bu] " 3
+.IP " " 3
a list of filenames:
-.RS 2
-.PP
-\f[CR]
- find\ -name\ \[aq]*\.[ch]\[aq]\ |\ sort\ |\ redo-stamp
-\f[]
+.RS +4n
+.nf
+.IP " " 3
+find -name '*.[ch]' | sort | redo-stamp
+.fi
.RE
-.IP \[bu] 2
+.IP " \[bu] " 3
+.IP " " 3
the contents of a web page:
-.RS 2
-.PP
-\f[CR]
- curl\ http://example\.org\ |\ redo-stamp
-\f[]
+.RS +4n
+.nf
+.IP " " 3
+curl http://example.org | redo-stamp
+.fi
.RE
.PP
-To ensure that your target gets checked every time, you might want
-to use \f[B]redo-always\f[](1)\.
+To ensure that your target gets checked every time, you
+might want to use \fBredo-always\fR(1).
.SH DISCUSSION
-.PP
-While using redo-stamp is simple, the way it works is harder to
-explain\. Deciding if a target is up to date or not is the job of
-\f[B]redo-ifchange\f[](1)\. Normally, a target is considered out of
-date when any of its dependencies (direct or indirect) have
-changed\. When that happens, \f[B]redo-ifchange\f[] runs the \.do
-script for the target, which regenerates the entire dependency
-list, including rebuilding any dependencies as necessary\.
+While using redo-stamp is simple, the way it
+works is harder to explain. Deciding if a target is
+up to date or not is the job of \fBredo-ifchange\fR(1).
+Normally, a target is considered out of date when any of its
+dependencies (direct or indirect) have changed. When that
+happens, \fBredo-ifchange\fR runs the .do script for the
+target, which regenerates the entire dependency list,
+including rebuilding any dependencies as necessary.
.PP
Imagine that we have the following dependency chain:
+.RS +4n
+.nf
.PP
-\f[CR]
- T\ ->\ X\ ->\ Y\ ->\ Z
-\f[]
-.PP
-T depends on X, which depends on Y, which depends on Z\. Now
-imagine someone has changed Z\.
-.PP
-If someone runs \f[B]redo-ifchange\ T\f[], then redo-ifchange
-checks if X is up to date; to do that, it checks if Y is up to
-date; and to do that, it checks whether Z is up to date - which it
-isn\[aq]t\. Thus, Y is not up to date, which means X isn\[aq]t,
-which means T isn\[aq]t either, and so we need to run T\.do\.
-\f[B]redo-ifchange\f[] won\[aq]t directly \f[B]redo\ X\f[] just
-because X is dirty; it redoes T, and T\.do might eventually call
-\f[B]redo-ifchange\ X\f[] if it needs to\.
-.PP
-When using redo-stamp, the behaviour is different\. Let\[aq]s say Y
-has used redo-stamp\. In the above sequence, Y is outdated because
-Z has changed\. However, we don\[aq]t know yet if Y\[aq]s stamp has
-changed, so we don\[aq]t yet know if we need to redo X, and thus we
-don\[aq]t know if we need to redo T\. We can\[aq]t just run
-\f[B]redo\ T\f[], because that could waste a lot of time if it
-turns out T didn\[aq]t need to be rebuilt after all\.
+T -> X -> Y -> Z
+.fi
+.RE
.PP
-What we do instead is note whether the \f[I]only\f[] dependencies
-of T that are out of date are \[aq]stamped\[aq] targets\. If
-\f[I]any\f[] dependencies of T are normal, out-of-date redo
-targets, then T needs to be rebuilt anyway; we don\[aq]t have to do
-anything special\.
+T depends on X, which depends on Y, which depends
+on Z. Now imagine someone has changed Z.
+.PP
+If someone runs \fBredo-ifchange T\fR, then redo-ifchange
+checks if X is up to date; to do that, it checks if Y
+is up to date; and to do that, it checks whether Z is up to
+date - which it isn't. Thus, Y is not up to date, which
+means X isn't, which means T isn't either, and so we need
+to run T.do. \fBredo-ifchange\fR won't directly \fBredo X\fR just
+because X is dirty; it redoes T, and T.do might eventually
+call \fBredo-ifchange X\fR if it needs to.
+.PP
+When using redo-stamp, the behaviour is different. Let's
+say Y has used redo-stamp. In the above sequence, Y is
+outdated because Z has changed. However, we don't know yet
+if Y's stamp has changed, so we don't yet know if we need
+to redo X, and thus we don't know if we need to redo T. We
+can't just run \fBredo T\fR, because that could waste a lot of
+time if it turns out T didn't need to be rebuilt after all.
+.PP
+What we do instead is note whether the \fIonly\fR dependencies
+of T that are out of date are 'stamped' targets. If \fIany\fR
+dependencies of T are normal, out-of-date redo targets,
+then T needs to be rebuilt anyway; we don't have to do
+anything special.
.PP
If the only dependency of T that has changed is Y (a
-\[aq]stamped\[aq] target), then we need to \f[B]redo\ Y\f[]
-automatically in order to determine if T needs to be rebuilt\. This
-is the only time that \f[B]redo\f[] ever rebuilds a target that
-hasn\[aq]t been explicitly asked for as part of a running \.do
-script\.
+'stamped' target), then we need to \fBredo Y\fR automatically
+in order to determine if T needs to be rebuilt. This is
+the only time that \fBredo\fR ever rebuilds a target that
+hasn't been explicitly asked for as part of a running .do
+script.
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-ifcreate\f[](1),
-\f[B]redo-ifchange\f[](1), \f[B]redo-always\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-ifcreate\fR(1), \fBredo-ifchange\fR(1), \fBredo-always\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
82 redo-targets.1
@@ -1,53 +1,51 @@
-.TH redo-targets 1 "2011-01-18" "Redo 0\.05"
+.TH REDO-TARGETS 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo-targets - print the list of all known redo targets
.SH SYNOPSIS
-.PP
redo-targets
.SH DESCRIPTION
-.PP
-redo-targets prints a list of all redo \f[I]target\f[] files that
-still exist\.
-.PP
-Files that no longer exist might not be targets anymore; you\[aq]ll
-have to redo them for them to end up back in this list\. (For
-example, if you built a file and then removed the file and its \.do
-file, you wouldn\[aq]t want it to show up in this list\.)
-.PP
-If a \.do script does not produce an output file (eg\. all\.do,
-clean\.do), it also does not show up in this list\.
-.PP
-The output of redo-targets might be useful in a semi-automated
-\f[B]clean\.do\f[] target; you could delete all the known targets,
-thus forcing them to be rebuilt next time\.
-.PP
-Each filename is on a separate line\. The filenames are not
-guaranteed to be in any particular order\.
-.PP
-All filenames are printed relative the current directory\. The list
-is not filtered in any way; it contains \f[I]all\f[] the target
-filenames from the entire project\. Remember that the redo database
-may span more than just your project, so you might need to filter
-the list before using it\. (A useful heuristic might be to remove
-any line starting with \[aq]\.\./\[aq] since it often refers to a
-target you don\[aq]t care about\.)
+redo-targets prints a list of all redo \fItarget\fR files that
+still exist.
+.PP
+Files that no longer exist might not be targets anymore;
+you'll have to redo them for them to end up back in this
+list. (For example, if you built a file and then removed
+the file and its .do file, you wouldn't want it to show up
+in this list.)
+.PP
+If a .do script does not produce an output file (eg.
+all.do, clean.do), it also does not show up in this list.
+.PP
+The output of redo-targets might be useful in a
+semi-automated \fBclean.do\fR target; you could delete all the
+known targets, thus forcing them to be rebuilt next time.
+.PP
+Each filename is on a separate line. The filenames are not
+guaranteed to be in any particular order.
+.PP
+All filenames are printed relative the current directory.
+The list is not filtered in any way; it contains \fIall\fR the
+target filenames from the entire project. Remember that
+the redo database may span more than just your project, so
+you might need to filter the list before using it. (A
+useful heuristic might be to remove any line starting with
+'../' since it often refers to a target you don't care
+about.)
.PP
If you want a list of only out-of-date targets, use
-\f[B]redo-ood\f[](1)\. If you want a list of sources (dependencies
-that aren\[aq]t targets), use \f[B]redo-sources\f[](1)\.
+\fBredo-ood\fR(1). If you want a list of sources (dependencies
+that aren't targets), use \fBredo-sources\fR(1).
.SH REDO
-.PP
-Part of the \f[B]redo\f[](1) suite\.
+Part of the \fBredo\fR(1) suite.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]redo\f[](1), \f[B]redo-ood\f[](1), \f[B]redo-sources\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBredo\fR(1), \fBredo-ood\fR(1), \fBredo-sources\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
View
475 redo.1
@@ -1,256 +1,245 @@
-.TH redo 1 "2011-01-18" "Redo 0\.05"
+.TH REDO 1 2011-12-31 "Redo 0.10" "User Commands"
+.ad l
+.nh
.SH NAME
-.PP
redo - rebuild target files when source files have changed
.SH SYNOPSIS
-.PP
-redo [options\.\.\.] [targets\.\.\.]
+redo [options...] [targets...]
.SH DESCRIPTION
-.PP
-redo is a simple yet powerful tool for rebuilding target files, and
-any of their dependencies, based on a set of rules\. The rules are
-encoded in simple \f[B]sh\f[](1) scripts called \[aq]\.do
-scripts\.\[aq]
-.PP
-redo supports GNU \f[B]make\f[](1)-style parallel builds using the
-\f[B]-j\f[] option; in fact, redo\[aq]s parallel jobserver is
-compatible with GNU Make, so redo and make can share build tokens
-with each other\. redo can call a sub-make (eg\. to build a
-subproject that uses Makefiles) or vice versa (eg\. if a make-based
-project needs to build a redo-based subproject)\.
-.PP
-Unlike make, redo does not have any special syntax of its own; each
-\f[I]target\f[] is built by running a \.do file, which is simply a
-shell script that redo executes for you with a particular
-environment and command-line arguments\.
-.PP
-If no \f[I]targets\f[] are specified, redo pretends you specified
-exactly one target named \f[B]all\f[]\.
-.PP
-Note that redo \f[I]always\f[] rebuilds the given targets (although
-it may skip rebuilding the targets\[aq] dependencies if they are up
-to date)\. If you only want to rebuild targets that are not up to
-date, use \f[B]redo-ifchange\f[](1) instead\.
-.PP
-A \.do script can call redo recursively to build its dependencies\.
+redo is a simple yet powerful tool for rebuilding target
+files, and any of their dependencies, based on a set of
+rules. The rules are encoded in simple \fBsh\fR(1) scripts
+called '.do scripts.'
+.PP
+redo supports GNU \fBmake\fR(1)-style parallel builds using the
+\fB-j\fR option; in fact, redo's parallel jobserver is compatible
+with GNU Make, so redo and make can share build tokens with
+each other. redo can call a sub-make (eg. to build a
+subproject that uses Makefiles) or vice versa (eg. if a
+make-based project needs to build a redo-based subproject).
+.PP
+Unlike make, redo does not have any special syntax of its
+own; each \fItarget\fR is built by running a .do file, which is
+simply a shell script that redo executes for you with a
+particular environment and command-line arguments.
+.PP
+If no \fItargets\fR are specified, redo pretends you specified
+exactly one target named \fBall\fR.
+.PP
+Note that redo \fIalways\fR rebuilds the given targets
+(although it may skip rebuilding the targets' dependencies
+if they are up to date). If you only want to rebuild
+targets that are not up to date, use \fBredo-ifchange\fR(1)
+instead.
+.PP
+A .do script can call redo recursively to build its
+dependencies.
.SH OPTIONS
-.TP
-.B -j, --jobs=\f[I]maxjobs\f[]
-execute at most \f[I]maxjobs\f[] \.do scripts in parallel\. The
-default value is 1\.
-.RS
-.RE
-.TP
-.B -d, --debug
-print dependency checks as they happen\. You can use this to figure
-out why a particular target is/isn\[aq]t being rebuilt when your
-\.do script calls it using \f[B]redo-ifchange\f[]\.
-.RS
-.RE
-.TP
-.B -v, --verbose
-pass the -v option to /bin/sh when executing scripts\. This
-normally causes the shell to echo the \.do script lines to stderr
-as it reads them\. Most shells will print the exact source line
-(eg\. \f[B]echo\ $3\f[]) and not the substituted value of variables
-(eg\. \f[B]echo\ mytarget\.redo\.tmp\f[])\.
-.RS
-.RE
-.TP
-.B -x, --xtrace
-pass the -x option to /bin/sh when executing scripts\. This
-normally causes the shell to echo exactly which commands are being
-executed\. Most shells will print the substituted variables (eg\.
-\f[B]echo\ mytarget\.redo\.tmp\f[]) and not the original source
-line (eg\. \f[B]echo\ $3\f[])\.
-.RS
-.RE
-.TP
-.B -k, --keep-going
-keep building as many targets as possible even if some of them
-return an error\. If one target fails, any target that depends on
-it also cannot be built, of course\.
-.RS
-.RE
-.TP
-.B --shuffle
-randomize the order in which requested targets are built\.
-Normally, if you run \f[B]redo\ a\ b\ c\f[], the targets will be
-built exactly in that order: first \f[B]a\f[], then \f[B]b\f[],
-then \f[B]c\f[]\. But if you use \f[B]-j\f[], they might end up
-being built in parallel, so it isn\[aq]t safe to rely on this
-precise ordering\. Using \f[B]--shuffle\f[], redo will build its
-targets in random order even without \f[B]-j\f[], which makes it
-easier to find accidental dependency problems of this sort\. NOTE:
-if you really just want to guarantee that \f[B]a\f[] is built, then
-\f[B]b\f[], then \f[B]c\f[], you can just run three \f[B]redo\f[]
-commands consecutively\. Because your \.do script is just a script,
-it will not be accidentally parallelized\.
-.RS
-.RE
-.TP
-.B --debug-locks
-print messages about acquiring, releasing, and waiting on locks\.
-Because redo can be highly parallelized, one instance may end up
-waiting for a target to be built by some other instance before it
-can continue\. If you suspect this is causing troubles, use this
-option to see which instance is waiting and when\.
-.RS
-.RE
-.TP
-.B --debug-pids
-add the process id of the particular redo instance to each output
-message\. This makes it easier to figure out which sub-instance of
-redo is doing what\.
-.RS
-.RE
+-j, --jobs=\fImaxjobs\fR
+: execute at most \fImaxjobs\fR .do scripts in parallel. The
+default value is 1.
+.PP
+-d, --debug
+: print dependency checks as they happen. You can use
+this to figure out why a particular target is/isn't being
+rebuilt when your .do script calls it using
+\fBredo-ifchange\fR.
+.PP
+-v, --verbose
+: pass the -v option to /bin/sh when executing scripts.
+This normally causes the shell to echo the .do script lines
+to stderr as it reads them. Most shells will print the
+exact source line (eg. \fBecho $3\fR) and not the
+substituted value of variables (eg. \fBecho
+mytarget.redo.tmp\fR).
+.PP
+-x, --xtrace
+: pass the -x option to /bin/sh when executing scripts.
+This normally causes the shell to echo exactly which
+commands are being executed. Most shells will print
+the substituted variables (eg. \fBecho
+mytarget.redo.tmp\fR) and not the original source line
+(eg. \fBecho $3\fR).
+.PP
+-k, --keep-going
+: keep building as many targets as possible even if some
+of them return an error. If one target fails, any
+target that depends on it also cannot be built, of course.
+.PP
+--shuffle
+: randomize the order in which requested targets are
+built. Normally, if you run \fBredo a b c\fR, the targets
+will be built exactly in that order: first \fBa\fR, then
+\fBb\fR, then \fBc\fR. But if you use \fB-j\fR, they might end up
+being built in parallel, so it isn't safe to rely on
+this precise ordering. Using \fB--shuffle\fR, redo will
+build its targets in random order even without \fB-j\fR,
+which makes it easier to find accidental dependency
+problems of this sort. NOTE: if you really just want
+to guarantee that \fBa\fR is built, then \fBb\fR, then \fBc\fR, you
+can just run three \fBredo\fR commands consecutively.
+Because your .do script is just a script, it will not
+be accidentally parallelized.
+.PP
+--debug-locks
+: print messages about acquiring, releasing, and waiting
+on locks. Because redo can be highly parallelized,
+one instance may end up waiting for a target to be
+built by some other instance before it can continue.
+If you suspect this is causing troubles, use this
+option to see which instance is waiting and when.
+.PP
+--debug-pids
+: add the process id of the particular redo instance to each
+output message. This makes it easier to figure out
+which sub-instance of redo is doing what.
+.PP
+--old-args
+: old versions of redo provided different definitions of
+the $1 and $2 parameters to .do scripts. The new
+version is compatible with djb's original
+specification. This option goes back to the old
+definitions so you can use .do scripts you haven't yet
+converted to the new style.
.SH DISCUSSION
+The core of redo is extremely simple. When you type \fBredo
+targetname\fR, then it will search for a matching .do file
+based on a simple algorithm. For example, given a target
+named \fBmytarget.a.b.c.d\fR, redo will look for a .do file in
+the following order:
+.IP " \[bu] " 3
+mytarget.a.b.c.d.do
+.IP " \[bu] " 3
+default.a.b.c.d.do
+.IP " \[bu] " 3
+default.b.c.d.do
+.IP " \[bu] " 3
+default.c.d.do
+.IP " \[bu] " 3
+default.d.do
+.IP " \[bu] " 3
+default.do
+.PP
+In all cases, the .do file must be in the same directory as
+the target file, or in one of the target's parent
+directories. For example, if given a target named
+\fB../a/b/xtarget.y\fR, redo will look for a .do file in the
+following order:
+.IP " \[bu] " 3
+$PWD/../a/b/xtarget.y
+.IP " \[bu] " 3
+$PWD/../a/b/default.y.do
+.IP " \[bu] " 3
+$PWD/../a/b/default.do
+.IP " \[bu] " 3
+$PWD/../a/default.y.do
+.IP " \[bu] " 3
+$PWD/../a/default.do
+.IP " \[bu] " 3
+$PWD/../default.y.do
+.IP " \[bu] " 3
+$PWD/../default.do
+.PP
+The first matching .do file is executed as a \fB/bin/sh\fR
+script. The .do script is always executed with the current
+working directory set to the directory containing the .do
+file. Because of that rule, the
+following two commands always have exactly identical
+behaviour:
+.RS +4n
+.nf
+.PP
+redo path/to/target
+
+cd path/to && redo target
+.fi
+.RE
.PP
-The core of redo is extremely simple\. When you type
-\f[B]redo\ targetname\f[], then it will search for a matching \.do
-file based on a simple algorithm\. For example, given a target
-named \f[B]mytarget\.a\.b\.c\.d\f[], redo will look for a \.do file
-in the following order:
-.IP \[bu] 2
-mytarget\.a\.b\.c\.d\.do
-.IP \[bu] 2
-default\.a\.b\.c\.d\.do
-.IP \[bu] 2
-default\.b\.c\.d\.do
-.IP \[bu] 2
-default\.c\.d\.do
-.IP \[bu] 2
-default\.d\.do
-.IP \[bu] 2
-default\.do
-.PP
-In all cases, the \.do file must be in the same directory as the
-target file, or in one of the target\[aq]s parent directories\. For
-example, if given a target named \f[B]\.\./a/b/xtarget\.y\f[], redo
-will look for a \.do file in the following order:
-.IP \[bu] 2
-$PWD/\.\./a/b/xtarget\.y
-.IP \[bu] 2
-$PWD/\.\./a/b/default\.y\.do
-.IP \[bu] 2
-$PWD/\.\./a/b/default\.do
-.IP \[bu] 2
-$PWD/\.\./a/default\.y\.do
-.IP \[bu] 2
-$PWD/\.\./a/default\.do
-.IP \[bu] 2
-$PWD/\.\./default\.y\.do
-.IP \[bu] 2
-$PWD/\.\./default\.do
-.PP
-The first matching \.do file is executed as a \f[B]/bin/sh\f[]
-script\. The \.do script is always executed with the current
-working directory set to the directory containing the \.do file\.
-Because of that rule, the following two commands always have
-exactly identical behaviour:
-.PP
-\f[CR]
- redo\ path/to/target
-
- cd\ path/to\ &&\ redo\ target
-\f[]
-.PP
-(Note: in \f[B]make\f[](1), these commands have confusingly
-different semantics\. The first command would look for a target
-named \f[B]path/to/target\f[] in \f[B]\./Makefile\f[], while the
-second command would look for a target named \f[B]target\f[] in
-\f[B]\./path/to/Makefile\f[]\. The two Makefiles might give
-completely different results, and it\[aq]s likely that the first
-command would have incomplete dependency information\. redo does
-not have this problem\.)
-.PP
-The three arguments passed to the \.do script are:
-.IP \[bu] 2
-$1: the basename of the target (eg\. mytarget\.a\.b)
-.IP \[bu] 2
-$2: the extension of the target, if any (eg\. \.c\.d)
-.IP \[bu] 2
-$3: a temporary filename that the \.do script should write its
-output to\.
-.PP
-Instead of using $3, the \.do script may also write the produced
-data to stdout\.
-.PP
-If the \.do file is in the same directory as the target, $1 and $3
-are guaranteed to be simple filenames (with no path component)\. If
-the \.do file is in a parent directory of the target, $1 and $3
-will be relative paths (ie\. will contain slashes)\.
-.PP
-redo is designed to update its targets atomically, and only if the
-do script succeeds (ie\. returns a zero exit code)\. Thus, you
-should never write directly to the target file, only to $3 or
-stdout\.
-.PP
-Normally, a \.do script will call other \.do scripts recursively,
-by running either \f[B]redo\f[] (which will always build the
-sub-target) or \f[B]redo-ifchange\f[] (which only rebuilds the
-sub-target if its dependencies have changed)\.
-.PP
-Running \f[B]redo-ifchange\f[] is also the way your \.do script
+(Note: in \fBmake\fR(1), these commands have confusingly
+different semantics. The first command would look for a
+target named \fBpath/to/target\fR in \fB./Makefile\fR, while the
+second command would look for a target named \fBtarget\fR in
+\fB./path/to/Makefile\fR. The two Makefiles might give
+completely different results, and it's likely that the
+first command would have incomplete dependency information.
+redo does not have this problem.)
+.PP
+The three arguments passed to the .do script are:
+.IP " \[bu] " 3
+$1: the target name (eg. mytarget.a.b)
+.IP " \[bu] " 3
+$2: the basename of the target, minus its extension (eg. mytarget)
+.IP " \[bu] " 3
+$3: a temporary filename that the .do script should write
+its output to.
+.PP
+Instead of using $3, the .do script may also write the
+produced data to stdout.
+.PP
+If the .do file is in the same directory as the target, $1
+is guaranteed to be a simple filename (with no path
+component). If the .do file is in a parent directory of
+the target, $1 and $3 will be relative paths (ie. will
+contain slashes).
+.PP
+redo is designed to update its targets atomically, and only
+if the do script succeeds (ie. returns a zero exit code).
+Thus, you should never write directly to the target file,
+only to $3 or stdout.
+.PP
+Normally, a .do script will call other .do scripts
+recursively, by running either \fBredo\fR (which will always
+build the sub-target) or \fBredo-ifchange\fR (which only
+rebuilds the sub-target if its dependencies have changed).
+.PP
+Running \fBredo-ifchange\fR is also the way your .do script
declares dependencies on other targets; any target that is
-\f[B]redo-ifchange\f[]d during your \.do script\[aq]s execution is
-both executed (if needed) and added as a dependency\.
+\fBredo-ifchange\fRd during your .do script's execution is both
+executed (if needed) and added as a dependency.
.PP
-You may have heard that \[aq]recursive make is considered
-harmful\[aq] (http://miller\.emu\.id\.au/pmiller/books/rmch/)\.
-Unlike \f[B]make\f[](1), redo does correct locking, state
+You may have heard that 'recursive make is considered
+harmful' (http://miller.emu.id.au/pmiller/books/rmch/).
+Unlike \fBmake\fR(1), redo does correct locking, state
management, and global dependency checking, so none of the
-arguments in that essay apply to redo\. In fact, recursive redo is
-really the only kind of redo\.
-.SH RELATED COMMANDS
-.PP
-When writing a \.do script, it will probably need to run one or
-more of the following commands:
-.TP
-.B \f[B]redo\f[]
-to build a sub-target unconditionally\.
-.RS
-.RE
-.TP
-.B \f[B]redo-ifchange\f[]
-to build a sub-target only if the sub-target\[aq]s dependencies
-have changed\.
-.RS
-.RE
-.TP
-.B \f[B]redo-ifcreate\f[]
-to tell redo that the current target must be rebuilt if a
-particular file gets created\.
-.RS
-.RE
-.TP
-.B \f[B]redo-always\f[]
-to tell redo that the current target must always be rebuilt, even
-if someone calls it using \f[B]redo-ifchange\f[]\. (This might
-happen if the current target has dependencies other than the
-contents of files\.)
-.RS
-.RE
-.TP
-.B \f[B]redo-stamp\f[]
-to tell redo that even though the current target has been rebuilt,
-it may not actually be any different from the previous version, so
-targets that depend on it might not need to be rebuilt\. Often used
-in conjunction with \f[B]redo-always\f[] to reduce the impact of
-always rebuilding a target\.
-.RS
-.RE
+arguments in that essay apply to redo. In fact, recursive
+redo is really the only kind of redo.
+.SH "RELATED COMMANDS"
+When writing a .do script, it will probably need to run
+one or more of the following commands:
+.PP
+\fBredo\fR
+: to build a sub-target unconditionally.
+.PP
+\fBredo-ifchange\fR
+: to build a sub-target only if the sub-target's
+dependencies have changed.
+.PP
+\fBredo-ifcreate\fR
+: to tell redo that the current target must be rebuilt if
+a particular file gets created.
+.PP
+\fBredo-always\fR
+: to tell redo that the current target must always be
+rebuilt, even if someone calls it using \fBredo-ifchange\fR.
+(This might happen if the current target has
+dependencies other than the contents of files.)
+.PP
+\fBredo-stamp\fR
+: to tell redo that even though the current target has
+been rebuilt, it may not actually be any different from
+the previous version, so targets that depend on it
+might not need to be rebuilt. Often used in
+conjunction with \fBredo-always\fR to reduce the impact of
+always rebuilding a target.
.SH CREDITS
-.PP
-The original concept for \f[B]redo\f[] was created by D\. J\.
+The original concept for \fBredo\fR 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\.
-.SH SEE ALSO
-.PP
-\f[B]sh\f[](1), \f[B]make\f[](1), \f[B]redo-ifchange\f[](1),
-\f[B]redo-ifcreate\f[](1), \f[B]redo-always\f[](1),
-\f[B]redo-stamp\f[](1)
+(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.
+.SH "SEE ALSO"
+\fBsh\fR(1), \fBmake\fR(1),
+\fBredo-ifchange\fR(1), \fBredo-ifcreate\fR(1), \fBredo-always\fR(1),
+\fBredo-stamp\fR(1)
.SH AUTHOR
-Avery Pennarun <apenwarr@gmail.com>
+Avery Pennarun \\<apenwarr@gmail.com>
Please sign in to comment.
Something went wrong with that request. Please try again.