Whoops, redo-oob was slightly wrong when used with -j.
We called 'redo' instead of 'redo-ifchange' on our indeterminate objects. Since other instances of redo-oob might be running at the same time, this could cause the same object to get rebuilt more than once unnecessarily. The unit tests caught this, I just didn't notice earlier.
This commit is contained in:
parent
e7f7119f2e
commit
91630a892a
3 changed files with 8 additions and 2 deletions
|
|
@ -12,11 +12,14 @@ deps = sys.argv[2:]
|
|||
|
||||
me = state.File(name=target)
|
||||
|
||||
argv = ['redo'] + deps
|
||||
os.environ['REDO_NO_OOB'] = '1'
|
||||
argv = ['redo-ifchange'] + deps
|
||||
rv = os.spawnvp(os.P_WAIT, argv[0], argv)
|
||||
if rv:
|
||||
sys.exit(rv)
|
||||
|
||||
# we know our caller already owns the lock on target, so we don't have to
|
||||
# acquire another one.
|
||||
os.environ['REDO_UNLOCKED'] = '1'
|
||||
argv = ['redo-ifchange', target]
|
||||
rv = os.spawnvp(os.P_WAIT, argv[0], argv)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue