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
|
|
|
#!/usr/bin/env python
|
2018-11-13 02:51:23 -05:00
|
|
|
import errno, fcntl, os, re, struct, sys, termios, time
|
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
|
|
|
import options
|
|
|
|
|
|
|
|
|
|
optspec = """
|
|
|
|
|
redo-log [options...] [targets...]
|
|
|
|
|
--
|
|
|
|
|
r,recursive show build logs for dependencies too
|
|
|
|
|
u,unchanged show lines for dependencies not needing to be rebuilt
|
|
|
|
|
f,follow keep watching for more lines to be appended (like tail -f)
|
|
|
|
|
no-details only show 'redo' recursion trace, not build output
|
|
|
|
|
no-colorize don't colorize 'redo' log messages
|
|
|
|
|
no-status don't display build summary line in --follow
|
|
|
|
|
ack-fd= (internal use only) print REDO-OK to this fd upon starting
|
|
|
|
|
"""
|
|
|
|
|
o = options.Options(optspec)
|
|
|
|
|
(opt, flags, extra) = o.parse(sys.argv[1:])
|
|
|
|
|
targets = extra
|
|
|
|
|
|
|
|
|
|
import vars_init
|
|
|
|
|
vars_init.init(list(targets))
|
|
|
|
|
|
|
|
|
|
import vars, state
|
|
|
|
|
|
|
|
|
|
already = set()
|
|
|
|
|
queue = []
|
|
|
|
|
depth = []
|
|
|
|
|
total_lines = 0
|
|
|
|
|
status = None
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# regexp for matching "redo" lines in the log, which we use for recursion.
|
|
|
|
|
# format:
|
|
|
|
|
# redo path/to/target which might have spaces
|
|
|
|
|
# redo [unchanged] path/to/target which might have spaces
|
|
|
|
|
# redo path/to/target which might have spaces (comment)
|
|
|
|
|
# FIXME: use a more structured format when writing the logs.
|
|
|
|
|
# That will prevent false positives and negatives. Then transform the
|
|
|
|
|
# structured format into a user-friendly format when printing in redo-log.
|
|
|
|
|
REDO_LINE_RE = re.compile(r'^redo\s+(\[\w+\] )?([^(:]+)( \([^)]+\))?\n$')
|
|
|
|
|
|
|
|
|
|
|
2018-11-13 02:51:23 -05:00
|
|
|
def _tty_width():
|
|
|
|
|
s = struct.pack("HHHH", 0, 0, 0, 0)
|
|
|
|
|
try:
|
|
|
|
|
import fcntl, termios
|
|
|
|
|
s = fcntl.ioctl(sys.stderr.fileno(), termios.TIOCGWINSZ, s)
|
|
|
|
|
except (IOError, ImportError):
|
|
|
|
|
return _atoi(os.environ.get('WIDTH')) or 70
|
|
|
|
|
(ysize,xsize,ypix,xpix) = struct.unpack('HHHH', s)
|
|
|
|
|
return xsize or 70
|
|
|
|
|
|
|
|
|
|
|
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 is_locked(fid):
|
|
|
|
|
return (fid is not None) and not state.Lock(fid=fid).trylock()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def catlog(t):
|
|
|
|
|
global total_lines, status
|
|
|
|
|
if t in already:
|
|
|
|
|
return
|
|
|
|
|
depth.append(t)
|
|
|
|
|
already.add(t)
|
|
|
|
|
if t == '-':
|
|
|
|
|
f = sys.stdin
|
|
|
|
|
fid = None
|
|
|
|
|
logname = None
|
|
|
|
|
else:
|
|
|
|
|
try:
|
|
|
|
|
sf = state.File(name=t, allow_add=False)
|
|
|
|
|
except KeyError:
|
|
|
|
|
sys.stderr.write('redo-log: %r: not known to redo.\n' % (t,))
|
|
|
|
|
sys.exit(24)
|
|
|
|
|
fid = sf.id
|
|
|
|
|
del sf
|
|
|
|
|
state.rollback()
|
|
|
|
|
logname = state.logname(fid)
|
|
|
|
|
f = None
|
|
|
|
|
delay = 0.01
|
|
|
|
|
was_locked = is_locked(fid)
|
|
|
|
|
line_head = ''
|
2018-11-13 02:51:23 -05:00
|
|
|
width = _tty_width()
|
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
|
|
|
while 1:
|
|
|
|
|
if not f:
|
|
|
|
|
try:
|
|
|
|
|
f = open(logname)
|
|
|
|
|
except IOError, e:
|
|
|
|
|
if e.errno == errno.ENOENT:
|
|
|
|
|
# ignore files without logs
|
|
|
|
|
pass
|
|
|
|
|
else:
|
|
|
|
|
raise
|
|
|
|
|
if f:
|
|
|
|
|
# Note: normally includes trailing \n.
|
|
|
|
|
# In 'follow' mode, might get a line with no trailing \n
|
|
|
|
|
# (eg. when ./configure is halfway through a test), which we
|
|
|
|
|
# deal with below.
|
|
|
|
|
line = f.readline()
|
|
|
|
|
else:
|
|
|
|
|
line = None
|
|
|
|
|
if not line and (not opt.follow or not was_locked):
|
|
|
|
|
# file not locked, and no new lines: done
|
|
|
|
|
break
|
|
|
|
|
if not line:
|
|
|
|
|
was_locked = is_locked(fid)
|
|
|
|
|
if opt.follow:
|
|
|
|
|
if opt.status:
|
2018-11-13 02:51:23 -05:00
|
|
|
width = _tty_width()
|
|
|
|
|
head = 'redo %s ' % ('{:,}'.format(total_lines))
|
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
|
|
|
tail = ''
|
2018-11-13 02:51:23 -05:00
|
|
|
for n in reversed(depth):
|
|
|
|
|
remain = width - len(head) - len(tail)
|
|
|
|
|
# always leave room for a final '... ' prefix
|
|
|
|
|
if remain < len(n) + 4 + 1 or remain <= 4:
|
|
|
|
|
if len(n) < 6 or remain < 6 + 1 + 4:
|
|
|
|
|
tail = '... %s' % tail
|
|
|
|
|
else:
|
|
|
|
|
start = len(n) - (remain - 3 - 1)
|
|
|
|
|
tail = '...%s %s' % (n[start:], tail)
|
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
|
|
|
break
|
2018-11-13 02:51:23 -05:00
|
|
|
elif n != '-':
|
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
|
|
|
tail = n + ' ' + tail
|
|
|
|
|
status = head + tail
|
2018-11-13 02:51:23 -05:00
|
|
|
if len(status) > width:
|
|
|
|
|
sys.stderr.write('\nOVERSIZE STATUS (%d):\n%r\n' %
|
|
|
|
|
(len(status), status))
|
|
|
|
|
assert(len(status) <= width)
|
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
|
|
|
sys.stdout.flush()
|
2018-11-13 02:51:23 -05:00
|
|
|
sys.stderr.write('\r%-*.*s\r' % (width, width, status))
|
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
|
|
|
time.sleep(min(delay, 1.0))
|
|
|
|
|
delay += 0.01
|
|
|
|
|
continue
|
|
|
|
|
total_lines += 1
|
|
|
|
|
delay = 0.01
|
|
|
|
|
if not line.endswith('\n'):
|
|
|
|
|
line_head += line
|
|
|
|
|
continue
|
|
|
|
|
if line_head:
|
|
|
|
|
line = line_head + line
|
|
|
|
|
line_head = ''
|
|
|
|
|
if status:
|
|
|
|
|
sys.stdout.flush()
|
2018-11-13 02:51:23 -05:00
|
|
|
sys.stderr.write('\r%-*.*s\r' % (width, width, ''))
|
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
|
|
|
status = None
|
|
|
|
|
g = re.match(REDO_LINE_RE, line)
|
|
|
|
|
if g:
|
|
|
|
|
attr, name, comment = g.groups()
|
|
|
|
|
if attr == '[unchanged] ':
|
|
|
|
|
if opt.unchanged:
|
|
|
|
|
if name not in already:
|
|
|
|
|
sys.stdout.write(line)
|
|
|
|
|
if opt.recursive:
|
|
|
|
|
catlog(name)
|
|
|
|
|
else:
|
|
|
|
|
sys.stdout.write(line)
|
|
|
|
|
if opt.recursive and (not comment or comment == ' (WAITING)'):
|
|
|
|
|
assert name
|
|
|
|
|
catlog(name)
|
|
|
|
|
else:
|
|
|
|
|
if opt.details:
|
|
|
|
|
sys.stdout.write(line)
|
|
|
|
|
if status:
|
|
|
|
|
sys.stdout.flush()
|
2018-11-13 02:51:23 -05:00
|
|
|
sys.stderr.write('\r%-*.*s\r' % (width, width, ''))
|
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
|
|
|
status = None
|
|
|
|
|
if line_head:
|
|
|
|
|
# partial line never got terminated
|
|
|
|
|
print line_head
|
|
|
|
|
assert(depth[-1] == t)
|
|
|
|
|
depth.pop(-1)
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
if not targets:
|
|
|
|
|
sys.stderr.write('redo-log: give at least one target; maybe "all"?\n')
|
|
|
|
|
sys.exit(1)
|
|
|
|
|
if opt.status < 2 and not os.isatty(2):
|
|
|
|
|
opt.status = False
|
|
|
|
|
if opt.ack_fd:
|
|
|
|
|
ack_fd = int(opt.ack_fd)
|
|
|
|
|
assert(ack_fd > 2)
|
|
|
|
|
if os.write(ack_fd, 'REDO-OK\n') != 8:
|
|
|
|
|
raise Exception('write to ack_fd returned wrong length')
|
|
|
|
|
os.close(ack_fd)
|
|
|
|
|
queue += targets
|
|
|
|
|
while queue:
|
|
|
|
|
t = queue.pop(0)
|
|
|
|
|
if t != '-':
|
|
|
|
|
print 'redo %s' % t
|
|
|
|
|
catlog(t)
|
|
|
|
|
except KeyboardInterrupt:
|
|
|
|
|
sys.exit(200)
|
|
|
|
|
except IOError, e:
|
|
|
|
|
if e.errno == errno.EPIPE:
|
|
|
|
|
pass
|
|
|
|
|
else:
|
|
|
|
|
raise
|