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

[Thomas Berg]

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