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

[Tom Tanner (BLOOMBERG/ LONDON)]

scons keeps signatures for built targets anyway. However it doesn't check them. It's possible it should do that as it protects you from people who accidentally change a built file by running a manual compile with different switches (or editting generate source code). However that doesn't come free (certainly not if you recalculate the signatures multiple times).

I think that'd give a better level of safety than deleting the database entry during the build (or marking it as 'needs build' which to my mind sounds a bit less risky)

----- Original Message -----
From: scons-users at scons.org
To: scons-users at scons.org
At: Jun  4 2014 15:01:00

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.
_______________________________________________
Scons-users mailing list
Scons-users at scons.org
http://four.pairlist.net/mailman/listinfo/scons-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20140606/0fe98441/attachment.html>