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

[Neil Turton]

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.  One fix to this bug
would be to mark the target(s) as unbuilt if a command fails.  A
better fix would be to mark the target(s) as unbuilt before invoking
the command as that would handle the case where scons dies.

neil at eagle:/tmp/foo$ cat SConstruct
Command(['output'], [], ARGUMENTS.get('command') + ' >$TARGET')
neil at eagle:/tmp/foo$ /tmp/scons/bin/scons -s command=date
neil at eagle:/tmp/foo$ cat output
Sat May 31 16:09:01 BST 2014
neil at eagle:/tmp/foo$ /tmp/scons/bin/scons -s command=false
scons: *** [output] Error 1
neil at eagle:/tmp/foo$ cat output
neil at eagle:/tmp/foo$ /tmp/scons/bin/scons -s command=date
neil at eagle:/tmp/foo$ cat output
neil at eagle:/tmp/foo$

William Deegan wrote:
> Below looks o.k. to me.
> I'm guessing scons assumes that if the command fails then there are no
> outputs generated.
> If that's the case the third invocations signature matches the first which
> completed successfully and so doesn't need to be rerun.
>
> If you think this is not reasonable, please bring it to the users mailing
> list for discussion.

I do think it's not reasonable.  If you modify the command to
something which fails and then modify the command back to the original
one, you should get the original output.  As far as I can see, the
same issue will exist for any command which uses shell output
redirection if that command can fail.  Here's another example.  Note
that the grep command fails if the string is not found.

neil at eagle:/tmp/foo$ cat SConstruct
Command(['bar'], ['foo'], "grep thing < $SOURCE > $TARGET")
neil at eagle:/tmp/foo$ echo thing1 > foo
neil at eagle:/tmp/foo$ scons -s
neil at eagle:/tmp/foo$ cat bar
thing1
neil at eagle:/tmp/foo$ echo 'error' > foo
neil at eagle:/tmp/foo$ scons -s
scons: *** [bar] Error 1
neil at eagle:/tmp/foo$ cat bar
neil at eagle:/tmp/foo$ echo thing1 > foo
neil at eagle:/tmp/foo$ scons -s
neil at eagle:/tmp/foo$ cat bar
neil at eagle:/tmp/foo$

Using shell redirection is recommended in the user guide:
> env.Command('foo.out', 'foo.in', "sed 's/x/y/' < $SOURCE > $TARGET")

This example will also fail if sed produces a non-zero exit code.

What do other people think?  Is this a bug in SCons or a user error?

Cheers, Neil.