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

[William Deegan]

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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://four.pairlist.net/pipermail/scons-users/attachments/20140603/ebc7f4c5/attachment.html>