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.

builder.py

@@ -73,7 +73,7 @@ class BuildJob:
         except ImmediateReturn, e:
             return self._after2(e.rv)
 
-        if dirty == True:
+        if vars.NO_OOB or dirty == True:
             self._start_do()
         else:
             self._start_oob(dirty)

redo-oob.py

@@ -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)

vars.py

@@ -25,3 +25,6 @@ while BASE and BASE.endswith('/'):
 
 UNLOCKED = os.environ.get('REDO_UNLOCKED', '') and 1 or 0
 os.environ['REDO_UNLOCKED'] = ''  # not inheritable by subprocesses
+
+NO_OOB = os.environ.get('REDO_NO_OOB', '') and 1 or 0
+os.environ['REDO_NO_OOB'] = ''    # not inheritable by subprocesses