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

Wed Jun 4 05:30:51 EDT 2014

As Bill said, scons doesn't check the md5 on targets, but if you want to you can write your own Decider to check them. Note this is a bit tricky as you'll get called multiple times for the same target and different sources and you'll only want to check the actual md5 matches the checked md5 once.

I think deleting targets after a failed build would be quicker though (arguably more irritating if you want to see the contents though).

----- Original Message -----
From: scons-users at scons.org
To: merlin66b at gmail.com, scons-users at scons.org
At: Jun  4 2014 05:07:58

SCons does assume that you don’t modify the output files from a build.
It only keeps the signatures for sources, not targets.

-Bill

On June 3, 2014 at 3:41:11 PM, Thomas Berg (merlin66b at gmail.com) wrote:

On Mon, Jun 2, 2014 at 3:38 PM, Neil Turton <nturton at tigris.org> wrote:

I've just filed a bug, but William Deegan suggested I raise the issue here.

http://scons.tigris.org/issues/show_bug.cgi?id=2950

See the session below.  The first invocation of scons creates the file
"output" with the command "date".  The second invocation causes
"output" to be overwritten, but scons does not mark the file as
unbuilt.  The third invocation does not rebuild "output", even though
it was overwritten by the second invocation.

A similar issue has been nagging us at my dayjob. We have some cases where SCons has been killed (in aborted Jenkins builds) rather than properly cancelled, meaning that SCons is not allowed to update its database file like it normally does at the end of a build.

Subsequent builds may then start to fail even if all the source files are correct, and the only reliable cure is to nuke the build directory to get everything rebuilt correctly.

Our problem has manifested itself only in C++ code generated by the qt4 moc tool. Strangely, it is hard to reproduce from scratch, for example by manually tampering with build products between runs. So I'm not sure if it is a general problem, or even a deterministic problem. By manual inspection after getting into this state, I can definitely see that the generated code is inconsistent with the input files. SCons still doesn't rebuild, even though the dependency tree is correct.

Since SCons has been very reliable in every other case we've thrown at it, my naive belief was that SCons would always correctly rebuild even in this case. The same goes for your case. It could for example verify the md5 hashes of files in the build directory like it does with source files, rather than just assuming that files are unchanged from the last successful build. Guess we've been too optimistic then?

We shouldn't be killing SCons in the first place, of course, so in our case we can't really claim it's a SCons bug (or can we?). But if SCons is really assuming that files in the build directory are unchanged, it certainly feels less robust than I thought it was.

Cheers,
Thomas

 _______________________________________________ 
Scons-users mailing list 
Scons-users at scons.org 
http://four.pairlist.net/mailman/listinfo/scons-users 

_______________________________________________ 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/20140604/993e8882/attachment.html>