@node Commands
@unnumbered Commands

There are three basic main commands, originally suggested by DJB in his
articles:

@table @command
@item redo
    Forcefully and sequentially build specified targets. This is the
    main command you will explicitly use from the command line. If no
    targets are given, then @file{all} target will be used by default.
@item redo-ifchange
    Rebuild specified targets if they are out-of-date and record them as
    a dependency for the currently run target. This is the main command
    you will use in @file{.do} files.
@item redo-ifcreate
    Record the non-existent file dependency for the currently run
    target. Target will be rebuilt if any of the given files appear. Can
    be used only inside @file{.do} file.
@end table

Pay attention that @command{redo-ifchange} enables parallel builds of
the given targets, but ordinary @command{redo} is not: it builds
specified targets sequentially and stops when error happens.

@option{-x} option can be used to enable tracing (@code{set -x}) of the
currently run shell script @file{.do} file. @option{-xx} option enables
tracing for all invoked @file{.do} files further.

With @option{-j} option you can enable parallel builds, probably with an
infinite number of workers (@code{=0}). Also you can set
@env{$REDO_JOBS} to automatically apply that setting globally.

Read about @ref{Logs, log storage capabilities}.

@option{-log-pid} (@env{$REDO_LOG_PID=1}) can be used to prefix job's
@code{stderr} with the PID, that could be useful during parallel builds.
@option{-d} (@env{$REDO_DEBUG=1}) enables debug messages.

@option{-no-progress} (@env{$REDO_NO_PROGRESS=1}) and
@option{-no-status} (@env{$REDO_NO_STATUS=1}) disable statusline and
progress display. @env{$NO_COLOR=1} disables progress/debug messages
colouring.

By default all build commands use @code{fsync} to assure data is reached
the disk. You can disable its usage with @env{$REDO_NO_SYNC=1}
environment variable, for speeding up the build process.

If redo sees some target modified externally, then by default it warns
user about that, does not build that target, but continues the build
process further. That is convenient in most cases: you can build your
project with manual targets alterings, without touching possibly more
complicated @file{.do} files. With @env{$REDO_STOP_IF_MODIFIED=1} redo
won't continue and will exit with failure message.

There are other commands that could be found in other implementations too:

@table @command
@item redo-always
    Record current target as an always-do dependency. By definition it
    should be always build. @command{goredo} tries to build it once per
    @strong{run}.
@item redo-stamp
    Record "stamp" dependency. It reads @code{stdin} and stores its hash
    in the dependency database. It is not used anyhow, it is dummy. Read
    about @ref{Stamping, stamping} in the FAQ. It is left only for
    compatibility with some other implementations.
@item redo-targets, redo-ood
    Show all known targets, possibly limited by specified directories.
    @command{redo-ood} shows only the out-of-date ones.
@item redo-sources
    Recursively show all source files the given targets depend on.
@item redo-affects
    It is not in other distributions, but it is some kind of opposite of
    @command{redo-sources} -- shows the targets that will be affected by
    specified files change.
@end table

And there are some maintenance and debug commands:

@table @command
@item redo-cleanup
    Removes either temporary (@option{tmp}), log files (@option{log}),
    or everything related to @command{goredo} (@option{full}).

@item redo-whichdo
    Display @file{.do} search paths for specified target (similar to
    @command{apenwarr/redo}):
@example
$ redo-whichdo x/y/a.b.o
x/y/a.b.o.do
x/y/default.b.o.do
x/y/default.o.do
x/y/default.do
x/default.b.o.do
x/default.o.do
x/default.do
default.b.o.do
default.o.do
default.do
../default.b.o.do
../default.o.do
../default.do
@end example

@item redo-dot
    Dependency
    @url{https://en.wikipedia.org/wiki/DOT_(graph_description_language), DOT}
    graph generator. For example to visualize your dependencies with GraphViz:
@example
$ redo target [...] # to assure that **/.redo/*.rec are filled up
$ redo-dot target [...] > whatever.dot
$ dot -Tpng whatever.dot > whatever.png # possibly add -Gsplines=ortho
@end example

@item redo-depfix
    When you copy your worktree to different place, then copied files
    ctime will change. And because recorded dependency information
    differs from updated ctimes, out-of-date algorithm will fallback to
    rereading the whole files for hash calculation, that is much slower.
    If you do not want to rebuild your targets from the ground, then
    @command{redo-depfix} can traverse through all dependency files and
    check if they have non-altered ctime values and update them in place.

@end table