@node Logs
@unnumbered Logs

@code{stderr} of the running targets can be kept on the disk by
specifying @option{-k} option (or by setting @env{$REDO_LOGS=1}
environment variable) to @command{redo}. You can simultaneously
use also @option{-s} option (@env{$REDO_SILENT=1} environment variable)
to silence @code{stderr} output, but still keeping it on the disk for
possible further debug investigation. @strong{Only} the latest build is
kept, previous one is overwritten.

@example
$ redo -xx -k -s build-the-whole-huge-project
@end example

Logs are stored in corresponding @file{.redo/tgt.log} file. Each line of
it is prefixed with @url{http://cr.yp.to/libtai/tai64.html, TAI64N}
timestamp, that you can decode with @command{tai64nlocal} utility from
@url{http://cr.yp.to/daemontools.html, daemontools}, or similar one:
@code{go get go.cypherpunks.ru/tai64n/cmd/tai64nlocal}.

When @option{-k} is in use, all environment variables, working
directory, command line arguments, start/finish times, duration,
participated PIDs, return codes are also saved in corresponding
@file{.redo/tgt.log.reg} file.

You can view any target's output with @command{redo-log} command
(possibly piping to @command{tai64nlocal}). @option{-c} option also
shows how exactly it was started, when started/finished and how long did
it take.

@option{-r} option enables recursive serialized indented output. When
you run @command{redo} in parallel, then all @code{stderr} (if no
@option{-s}ilence was enabled) is printed as it appears, mixing output
from all commands, that is hard to read and investigate. Serialized
@command{redo-log} output rearranges output. I will take example from
original apenwarr's idea @url{https://apenwarr.ca/log/20181106,
article}. Serialized output will look like this:

@verbatim
$ redo-log -r A
A: ...A stuff...
A: redo-ifchange J
J: > redo J
J: > ...J stuff...
J: > redo-ifchange X Y
X: > > redo X
X: > > ...X stuff...
X: > > done X
J: > > redo Y
Y: > > ...Y stuff...
Z: > > > redo Z
Z: > > > ...Z stuff...
Z: > > > done Z
Y: > > ...more Y stuff...
Y: > > done Y
J: > ...more J stuff...
J: > done J
A: ...more A stuff...
@end verbatim

It will output depth first logs. It can rearrange some "events" (redo
invocations): failed targets will be at the very end, because they are
the most interesting ones for the human.

Pay attention that recursive output is more CPU hungry. Single target
output is literally copying of @file{.redo/tgt.log} file to @code{stdout}.