2010-12-11 18:32:40 -08:00
|
|
|
import sys, os
|
|
|
|
|
import vars
|
|
|
|
|
|
redo-log: capture and linearize the output of redo builds.
redo now saves the stderr from every .do script, for every target, into
a file in the .redo directory. That means you can look up the logs
from the most recent build of any target using the new redo-log
command, for example:
redo-log -r all
The default is to show logs non-recursively, that is, it'll show when a
target does redo-ifchange on another target, but it won't recurse into
the logs for the latter target. With -r (recursive), it does. With -u
(unchanged), it does even if redo-ifchange discovered that the target
was already up-to-date; in that case, it prints the logs of the *most
recent* time the target was generated.
With --no-details, redo-log will show only the 'redo' lines, not the
other log messages. For very noisy build systems (like recursing into
a 'make' instance) this can be helpful to get an overview of what
happened, without all the cruft.
You can use the -f (follow) option like tail -f, to follow a build
that's currently in progress until it finishes. redo itself spins up a
copy of redo-log -r -f while it runs, so you can see what's going on.
Still broken in this version:
- No man page or new tests yet.
- ANSI colors don't yet work (unless you use --raw-logs, which gives
the old-style behaviour).
- You can't redirect the output of a sub-redo to a file or a
pipe right now, because redo-log is eating it.
- The regex for matching 'redo' lines in the log is very gross.
Instead, we should put the raw log files in a more machine-parseable
format, and redo-log should turn that into human-readable format.
- redo-log tries to "linearize" the logs, which makes them
comprehensible even for a large parallel build. It recursively shows
log messages for each target in depth-first tree order (by tracing
into a new target every time it sees a 'redo' line). This works
really well, but in some specific cases, the "topmost" redo instance
can get stuck waiting for a jwack token, which makes it look like the
whole build has stalled, when really redo-log is just waiting a long
time for a particular subprocess to be able to continue. We'll need to
add a specific workaround for that.
2018-11-03 22:09:18 -04:00
|
|
|
|
|
|
|
|
def check_tty():
|
|
|
|
|
global RED, GREEN, YELLOW, BOLD, PLAIN
|
|
|
|
|
if sys.stderr.isatty() and (os.environ.get('TERM') or 'dumb') != 'dumb':
|
|
|
|
|
# ...use ANSI formatting codes.
|
|
|
|
|
RED = "\x1b[31m"
|
|
|
|
|
GREEN = "\x1b[32m"
|
|
|
|
|
YELLOW = "\x1b[33m"
|
|
|
|
|
BOLD = "\x1b[1m"
|
|
|
|
|
PLAIN = "\x1b[m"
|
|
|
|
|
else:
|
|
|
|
|
RED = ""
|
|
|
|
|
GREEN = ""
|
|
|
|
|
YELLOW = ""
|
|
|
|
|
BOLD = ""
|
|
|
|
|
PLAIN = ""
|
|
|
|
|
|
|
|
|
|
check_tty()
|
2011-01-04 23:39:48 +11:00
|
|
|
|
|
|
|
|
|
2010-12-11 18:32:40 -08:00
|
|
|
def log_(s):
|
|
|
|
|
sys.stdout.flush()
|
|
|
|
|
if vars.DEBUG_PIDS:
|
|
|
|
|
sys.stderr.write('%d %s' % (os.getpid(), s))
|
|
|
|
|
else:
|
|
|
|
|
sys.stderr.write(s)
|
|
|
|
|
sys.stderr.flush()
|
|
|
|
|
|
|
|
|
|
|
2011-01-04 23:39:48 +11:00
|
|
|
def log(s):
|
|
|
|
|
log_(''.join([GREEN, "redo ", vars.DEPTH, BOLD, s, PLAIN]))
|
2010-12-11 18:32:40 -08:00
|
|
|
|
2011-01-04 23:39:48 +11:00
|
|
|
def err(s):
|
|
|
|
|
log_(''.join([RED, "redo ", vars.DEPTH, BOLD, s, PLAIN]))
|
2010-12-11 18:32:40 -08:00
|
|
|
|
2011-01-04 23:39:48 +11:00
|
|
|
def warn(s):
|
|
|
|
|
log_(''.join([YELLOW, "redo ", vars.DEPTH, BOLD, s, PLAIN]))
|
2010-12-11 18:32:40 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
def debug(s):
|
|
|
|
|
if vars.DEBUG >= 1:
|
|
|
|
|
log_('redo: %s%s' % (vars.DEPTH, s))
|
|
|
|
|
def debug2(s):
|
|
|
|
|
if vars.DEBUG >= 2:
|
|
|
|
|
log_('redo: %s%s' % (vars.DEPTH, s))
|
|
|
|
|
def debug3(s):
|
|
|
|
|
if vars.DEBUG >= 3:
|
|
|
|
|
log_('redo: %s%s' % (vars.DEPTH, s))
|