[Scons-users] Failed command does not invalidate the target

Neil Turton nturton at tigris.org
Wed Jun 4 10:00:47 EDT 2014


I agree with Gary that in my case, the builder wrote a partial output
file and then failed.  If SCons were to delete the output file after a
failed build then that would be an improvement.  But I think there is
a better solution.

As Tom points out, that won't handle the case where SCons gets
terminated with extreme prejudice.  As I understand it, SCons keeps
signatures in a database to track which sources were used to build
each target.  If SCons were to remove the database entry for the
target before building the target then it wouldn't matter if SCons got
terminated.  It would know that the target needed to be rebuilt when
next invoked.  The process would be:
  1. SCons gets invoked to build the file "target"
  2. SCons examines the database entry for "target"
  3. SCons checks signatures of source files and determines that
"target" needs to be rebuilt
  4. SCons removes the database entry for "target"
  5. SCons invokes the command to build "target"
  6. The test system kills SCons and the invoked command
  7. The source files get reverted to match the signatures in the
original database entry
  8. SCons gets invoked to build the file "target"
  9. SCons finds there is no database entry for "target"
 10. SCons invokes the command to build "target"

Step 7 is what causes the problem.  Step 4 is new and makes sure that
SCons considers the target to be out-of-date at step 9.  This also
handles the case where the command fails, but SCons didn't get
terminated.

Alternatively, the problem would also be solved by keeping signatures
of all targets.  I guess that most target files are also source files
for other rules, so if there was a cache of md5 values which was
shared for sources and targets then the overhead would only be for
final targets.  However, that might be a lot of effort to implement.

Cheers,
Neil.


More information about the Scons-users mailing list