4 There are three basic main commands, originally suggested by DJB in his
9 Forcefully and sequentially build specified targets. This is the
10 main command you will explicitly use from the command line. If no
11 targets are given, then @file{all} target will be used by default.
13 Rebuild specified targets if they are out-of-date and record them as
14 a dependency for the currently run target. This is the main command
15 you will use in @file{.do} files.
17 Record the non-existent file dependency for the currently run
18 target. Target will be rebuilt if any of the given files appear. Can
19 be used only inside @file{.do} file.
22 Pay attention that @command{redo-ifchange} enables parallel builds of
23 the given targets, but ordinary @command{redo} is not: it builds
24 specified targets sequentially and stops when error happens.
26 @option{-x} option can be used to enable tracing (@code{set -x}) of the
27 currently run shell script @file{.do} file. @option{-xx} option enables
28 tracing for all invoked @file{.do} files further.
30 With @option{-j} option you can enable parallel builds, probably with an
31 infinite number of workers (@code{=0}). Also you can set
32 @env{$REDO_JOBS} to automatically apply that setting globally.
34 Read about @ref{Logs, log storage capabilities}.
36 @option{-log-pid} (@env{$REDO_LOG_PID=1}) can be used to prefix job's
37 @code{stderr} with the PID, that could be useful during parallel builds.
38 @option{-d} (@env{$REDO_DEBUG=1}) enables debug messages.
40 @option{-no-progress} (@env{$REDO_NO_PROGRESS=1}) and
41 @option{-no-status} (@env{$REDO_NO_STATUS=1}) disable statusline and
42 progress display. @env{$NO_COLOR=1} disables progress/debug messages
45 By default all build commands use @code{fsync} to assure data is reached
46 the disk. You can disable its usage with @env{$REDO_NO_SYNC=1}
47 environment variable, for speeding up the build process.
49 @command{goredo} determines target is out-of-date by comparing its size,
50 @code{ctime} and content's hash, if @code{ctime} differs. Depending on
51 the filesystem you use, probably you can not trust its @code{ctime}
52 value at all. In that case you can set @env{$REDO_INODE_NO_TRUST=1} to
53 forcefully verify the hash.
55 There are other commands that could be found in other implementations too:
59 Record current target as an always-do dependency. By definition it
60 should be always build. @command{goredo} tries to build it once per
63 Record "stamp" dependency. It reads @code{stdin} and stores its hash
64 in the dependency database. It is not used anyhow, it is dummy. Read
65 about @ref{Stamping, stamping} in the FAQ. It is left only for
66 compatibility with some other implementations.
67 @item redo-targets, redo-ood
68 Show all known targets, possibly limited by specified directories.
69 @command{redo-ood} shows only the out-of-date ones.
71 Recursively show all source files the given targets depend on.
73 It is not in other distributions, but it is some kind of opposite of
74 @command{redo-sources} -- shows the targets that will be affected by
75 specified files change.
78 And there are some maintenance and debug commands:
82 Removes either temporary (@option{tmp}), log files (@option{log}),
83 or everything related to @command{goredo} (@option{full}).
85 Display @file{.do} search paths for specified target (similar to
86 @command{apenwarr/redo}):
88 $ redo-whichdo x/y/a.b.o
105 @url{https://en.wikipedia.org/wiki/DOT_(graph_description_language), DOT}
106 graph generator. For example to visualize your dependencies with GraphViz:
108 $ redo target [...] # to assure that **/.redo/*.rec are filled up
109 $ redo-dot target [...] > whatever.dot
110 $ dot -Tpng whatever.dot > whatever.png # possibly add -Gsplines=ortho