Add option to delete targets for failed actions simliar to make's DELETE_ON_ERROR

[zapta]

Describe the bug
When a command fails after writing its output file, SCons doesn't delete the target file.
Add feature like make's DELETE_ON_ERROR to allow optional deletion of targets of actions which error out.
See also StackOverFlow question

Required information

• Link to SCons Users thread discussing your issue.

https://pairlist4.pair.net/pipermail/scons-users/2025-July/009515.html

• Version of SCons
  4.8.1

• Version of Python
  3.13.1

• Which python distribution if applicable (python.org, cygwin, anaconda, macports, brew,etc)

python.org (I think)

• How you installed SCons

pip install scons

• What Platform are you on? (Linux/Windows and which version)

macOS 15.5 Apple Silicon

• How to reproduce your issue?

Extract the three files below SConstruct, command.sh and run.sh, make command.sh and run.sh executable and run run.sh.

The command command.sh copies file1 to file2. If file1 starts with 'bad' it exits with an error code to simulate a crash after the output file was written. SCons is executed three times with file1 having the content "good", "bad", and "good" respectively. At the end of the third scons runs we expect file2 to have "good" but it contains "bad".

1. File SConstruct:

# SCons environment
env = Environment()

# Copy file1 → file2 using command.sh
# Inject an error if file1 starts with 'bad"
file2 = env.Command(
    target='file2',
    source='file1',
    action='./command.sh $SOURCE $TARGET'
)

# Make 'file2' the default target
Default(file2)

2. File command.sh:

#!/bin/bash
# Usage: ./command input > output

# Copy source to destination
cp "$1" "$2"

# If the input file stats with 'bad' inject an error AFTER creating the output file.

first_line=$(head -n 1 "$1")

if [[ "$first_line" == bad* ]]; then
  exit 1
fi

exit 0

3. File run.sh:

#!/bin/bash

# Clean up.
rm -f .sconsign.dblite
rm -f file[12]

values=('good' 'bad' 'good')

i=0
for val in "${values[@]}"; do
  ((i++))
  echo
  echo "----- Iteration $i: file1 = '$val' -----"

  echo
  echo "$val" > file1
  scons

  echo
  echo "File1"
  md5 file1
  cat -n file1

  echo
  echo "File2"
  md5 file2
  cat -n file2

  echo
  echo "DBlite:"
  sconsign  .sconsign.dblite
done

exit 

4. Output log

$ ./run.sh 

----- Iteration 1: file1 = 'good' -----

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
./command.sh file1 file2
scons: done building targets.

File1
MD5 (file1) = d7f986677d9f563bd1794b09d82206a3
     1	good

File2
MD5 (file2) = d7f986677d9f563bd1794b09d82206a3
     1	good

DBlite:
=== .:
file1: d7f986677d9f563bd1794b09d82206a3 1752702994 5
file2: d7f986677d9f563bd1794b09d82206a3 1752702995 5
        file1: d7f986677d9f563bd1794b09d82206a3 1752702994 5
        2dbc2dce125a753309a27b7d5157aaaa [./command.sh $SOURCE $TARGET]

----- Iteration 2: file1 = 'bad' -----

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
./command.sh file1 file2
scons: *** [file2] Error 1
scons: building terminated because of errors.

File1
MD5 (file1) = df207dc9143c6fabf60b69b9c3035103
     1	bad

File2
MD5 (file2) = df207dc9143c6fabf60b69b9c3035103
     1	bad

DBlite:
=== .:
file1: df207dc9143c6fabf60b69b9c3035103 1752702995 4
file2: d7f986677d9f563bd1794b09d82206a3 1752702995 5
        file1: d7f986677d9f563bd1794b09d82206a3 1752702994 5
        2dbc2dce125a753309a27b7d5157aaaa [./command.sh $SOURCE $TARGET]

----- Iteration 3: file1 = 'good' -----

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: `file2' is up to date.
scons: done building targets.

File1
MD5 (file1) = d7f986677d9f563bd1794b09d82206a3
     1	good

File2
MD5 (file2) = df207dc9143c6fabf60b69b9c3035103
     1	bad

DBlite:
=== .:
file1: d7f986677d9f563bd1794b09d82206a3 1752702995 5
file2: d7f986677d9f563bd1794b09d82206a3 1752702995 4
        file1: d7f986677d9f563bd1794b09d82206a3 1752702995 5
        2dbc2dce125a753309a27b7d5157aaaa [./command.sh $SOURCE $TARGET]
/projects/apio-dev/repo/experimental/scons_bug$ 

• How you invoke scons (The command line you're using "scons --flags some_arguments")

Running scons three times via run.sh.

[bdbaddog]

Files for example
4747.tgz

[zapta]

Hi @bdbaddog, can you explain what 'Add option to delete targets for failed actions simliar to make's DELETE_ON_ERROR mean?

I think that SCons should handle this example correctly by default, without having to have a special configuration. If this will come at a significant computational cost, the option should be to disable it, at the user's risk. That is, conservative correctness as the default.

[bdbaddog]

SCons as with most build systems has an expectation that if a build command fails, no files are generated.

Make has an optional way to delete target files for build targets which fail.
If SCons had such, then setting that optional behavoir would resolve your issue.

(Though I've already pointed out in email that you just need to change one script and your build will work).

So therefore I'll categorize this request as an enhancement request.

[zapta]

The example we provided is just an simplified example to demonstrate the issue we have with a real life command that we don't control so it's not something we can fix.

I may missed the part about DELETE_ON_FAILURE, is in an existing env var that SCons currently observes or just a feature request?

After the third invocation SCons reports that everything is build OK but there is a discrepancy between the actual MD5 of file2 and the one in the database. Is this acceptable?

[bdbaddog]

Please reread my previous comment.
Also don't post screenshots, just post the text.

[zapta]

Do you mean DELETE_ON_ERROR?

https://www.gnu.org/software/make/manual/html_node/Special-Targets.html

[bdbaddog]

Yes, updated above text.

[zapta]

I see. Yes, this will do it. Or potentially, SCons can just mark them in the database as dirty.

Thanks for looking into it!

[zapta]

The "Fix Issue 4747" record above is not related to this issue.

[bdbaddog]

The "Fix Issue 4747" record above is not related to this issue.

I updated the commit message, so in theory the tag above should go away?