2018-12-14 08:38:53 +00:00
|
|
|
"""redo-ifchange: build the given targets if they have changed."""
|
Further improve handling of symlink targets/deps.
In commit redo-0.11-4-g34669fb, we changed os.stat into os.lstat to
avoid false positives in the "manual override" detector: a .do file
that generates $3 as a symlink would trigger manual override if the
*target* of that symlink ever changed, which is incorrect.
Unfortunately using os.lstat() leads to a different problem: if X
depends on Y and Y is a symlink to Z, then X would not be rebuilt when
Z changes, which is clearly wrong.
The fix is twofold:
1. read_stamp() should change on changes to both the link itself,
*and* the target of the link.
2. We shouldn't mark a target as overridden under so many situations.
We'll use *only* the primary mtime of the os.lstat(), not all the
other bits in the stamp.
Step 2 fixes a few other false positives also. For example, if you
'cp -a' a whole tree to another location, the st_ino of all the targets
will change, which would trigger a mass of "manual override" warnings.
Although a change in inode is sufficient to count an input as having
changed (just to be extra safe), it should *not* be considered a manual
override. Now we can distinguish between the two.
Because the stamp format has changed, update the SCHEMA_VER field. I
should have done this every other time I changed the stamp format, but
I forgot. Sorry. That leads to spurious "manually modified" warnings
after upgrading redo.
2018-11-21 07:19:20 -05:00
|
|
|
import os, sys, traceback
|
2018-12-11 00:55:05 +00:00
|
|
|
from . import env, builder, deps, jobserver, logs, state
|
2018-12-05 02:34:36 -05:00
|
|
|
from .logs import debug2, err
|
2010-11-13 00:45:49 -08:00
|
|
|
|
2018-12-05 01:07:16 -05:00
|
|
|
|
2010-11-21 04:14:52 -08:00
|
|
|
def should_build(t):
|
2010-12-07 02:17:22 -08:00
|
|
|
f = state.File(name=t)
|
2010-12-10 20:53:31 -08:00
|
|
|
if f.is_failed():
|
|
|
|
|
raise builder.ImmediateReturn(32)
|
2018-12-05 01:07:16 -05:00
|
|
|
dirty = deps.isdirty(f, depth='', max_changed=env.v.RUNID,
|
2018-10-30 23:03:46 -04:00
|
|
|
already_checked=[])
|
2018-12-02 23:15:37 -05:00
|
|
|
return f.is_generated, dirty == [f] and deps.DIRTY or dirty
|
2010-11-21 04:14:52 -08:00
|
|
|
|
|
|
|
|
|
2018-12-02 23:15:37 -05:00
|
|
|
def main():
|
|
|
|
|
rv = 202
|
2010-11-21 21:15:24 -08:00
|
|
|
try:
|
2018-12-05 01:07:16 -05:00
|
|
|
targets = sys.argv[1:]
|
|
|
|
|
state.init(targets)
|
|
|
|
|
if env.is_toplevel and not targets:
|
|
|
|
|
targets = ['all']
|
|
|
|
|
if env.is_toplevel and env.v.LOG:
|
2018-12-02 23:15:37 -05:00
|
|
|
builder.close_stdin()
|
|
|
|
|
builder.start_stdin_log_reader(
|
|
|
|
|
status=True, details=True,
|
|
|
|
|
pretty=True, color=True, debug_locks=False, debug_pids=False)
|
2018-12-11 00:55:05 +00:00
|
|
|
else:
|
Workaround for completely broken file locking on Windows 10 WSL.
WSL (Windows Services for Linux) provides a Linux-kernel-compatible ABI
for userspace processes, but the current version doesn't not implement
fcntl() locks at all; it just always returns success. See
https://github.com/Microsoft/WSL/issues/1927.
This causes us three kinds of problem:
1. sqlite3 in WAL mode gives "OperationalError: locking protocol".
1b. Other sqlite3 journal modes also don't work when used by
multiple processes.
2. redo parallelism doesn't work, because we can't prevent the same
target from being build several times simultaneously.
3. "redo-log -f" doesn't work, since it can't tell whether the log
file it's tailing is "done" or not.
To fix #1, we switch the sqlite3 journal back to PERSIST instead of
WAL. We originally changed to WAL in commit 5156feae9d to reduce
deadlocks on MacOS. That was never adequately explained, but PERSIST
still acts weird on MacOS, so we'll only switch to PERSIST when we
detect that locking is definitely broken. Sigh.
To (mostly) fix #2, we disable any -j value > 1 when locking is broken.
This prevents basic forms of parallelism, but doesn't stop you from
re-entrantly starting other instances of redo. To fix that properly,
we need to switch to a different locking mechanism entirely, which is
tough in python. flock() locks probably work, for example, but
python's locks lie and just use fcntl locks for those.
To fix #3, we always force --no-log mode when we find that locking is
broken.
2019-01-02 14:18:51 -05:00
|
|
|
logs.setup(
|
|
|
|
|
tty=sys.stderr, parent_logs=env.v.LOG,
|
|
|
|
|
pretty=env.v.PRETTY, color=env.v.COLOR)
|
2018-12-05 01:07:16 -05:00
|
|
|
if env.v.TARGET and not env.v.UNLOCKED:
|
|
|
|
|
me = os.path.join(env.v.STARTDIR,
|
|
|
|
|
os.path.join(env.v.PWD, env.v.TARGET))
|
2018-12-02 23:15:37 -05:00
|
|
|
f = state.File(name=me)
|
|
|
|
|
debug2('TARGET: %r %r %r\n'
|
2018-12-05 01:07:16 -05:00
|
|
|
% (env.v.STARTDIR, env.v.PWD, env.v.TARGET))
|
2018-12-02 23:15:37 -05:00
|
|
|
else:
|
|
|
|
|
f = me = None
|
|
|
|
|
debug2('redo-ifchange: not adding depends.\n')
|
jobserver: allow overriding the parent jobserver in a subprocess.
Previously, if you passed a -j option to a redo process in a redo or
make process hierarchy with MAKEFLAGS already set, it would ignore the
-j option and continue using the jobserver provided by the parent.
With this change, we instead initialize a new jobserver with the
desired number of tokens, which is what GNU make does in the same
situation. A typical use case for this is to force serialization of
build steps in a subtree (by using -j1). In make, this is often useful
for "fixing" makefiles that haven't been written correctly for parallel
builds. In redo, that happens much less often, but it's useful at
least in unit tests.
Passing -j1 is relatively harmless (the redo you are starting inherits
a token anyway, so it doesn't create any new tokens). Passing -j > 1
is more risky, because it creates new tokens, thus increasing the level
of parallelism in the system. Because this may not be what you wanted,
we print a warning when you pass -j > 1 to a sub-redo. GNU make gives
a similar warning in this situation.
2018-12-31 18:57:58 -05:00
|
|
|
jobserver.setup(0)
|
2018-10-06 04:36:24 -04:00
|
|
|
try:
|
2018-12-02 23:15:37 -05:00
|
|
|
if f:
|
|
|
|
|
for t in targets:
|
|
|
|
|
f.add_dep('m', t)
|
|
|
|
|
f.save()
|
|
|
|
|
state.commit()
|
2018-12-11 02:57:29 +00:00
|
|
|
rv = builder.run(targets, should_build)
|
2018-10-06 04:36:24 -04:00
|
|
|
finally:
|
redo-log: prioritize the "foreground" process.
When running a parallel build, redo-log -f (which is auto-started by
redo) tries to traverse through the logs depth first, in the order
parent processes started subprocesses. This works pretty well, but if
its dependencies are locked, a process might have to give up its
jobserver token while other stuff builds its dependencies. After the
dependency finishes, the parent might not be able to get a token for
quite some time, and the logs will appear to stop.
To prevent this from happening, we can instantiate up to one "cheater"
token, only in the foreground process (the one locked by redo-log -f),
which will allow it to continue running, albeit a bit slowly (since it
only has one token out of possibly many). When the process finishes,
we then destroy the fake token. It gets a little complicated; see
explanation at the top of jwack.py.
2018-11-17 04:32:09 -05:00
|
|
|
try:
|
2018-12-02 23:15:37 -05:00
|
|
|
state.rollback()
|
|
|
|
|
finally:
|
|
|
|
|
try:
|
2018-12-04 23:20:14 -05:00
|
|
|
jobserver.force_return_tokens()
|
2018-12-02 23:15:37 -05:00
|
|
|
except Exception, e: # pylint: disable=broad-except
|
|
|
|
|
traceback.print_exc(100, sys.stderr)
|
|
|
|
|
err('unexpected error: %r\n' % e)
|
|
|
|
|
rv = 1
|
|
|
|
|
except KeyboardInterrupt:
|
2018-12-05 01:07:16 -05:00
|
|
|
if env.is_toplevel:
|
2018-12-02 23:15:37 -05:00
|
|
|
builder.await_log_reader()
|
|
|
|
|
sys.exit(200)
|
|
|
|
|
state.commit()
|
2018-12-05 01:07:16 -05:00
|
|
|
if env.is_toplevel:
|
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
|
|
|
builder.await_log_reader()
|
2018-12-02 23:15:37 -05:00
|
|
|
sys.exit(rv)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
|
main()
|