Crash passing construction variable as target for env.Program()

[bdbaddog]

This issue was originally created at: 2009-04-24 12:54:20.
This issue was reported by: rspangler.

rspangler said at 2009-04-24 12:54:20

The following SConstruct:

e = Environment(tools=['msvc', 'mslink'], HELLO='hello')
e.Program('$HELLO', [])

causes SCons to die:

scons: Reading SConscript files ...

(and that's all the output I get; scons --debug=stacktrace is the same output)

An older version of SCons (0.98.2) also dies, but reports the following more-helpful error:

scons: Reading SConscript files ...
scons: *** AttributeError `'str' object has no attribute 'exe'' trying to evaluate `$HELLO.exe'

Enclosing the variable in ${} is a workaround:

e = Environment(tools=['msvc', 'mslink'], HELLO='hello')
e.Program('${HELLO}', [])

gregnoel said at 2009-05-13 20:22:40

Bug party triage. Issue #804 and issue #2404 both deal with "lazy actions" where the command evaluation is delayed until later. It may well be that they are dups; at a minimum, they should be worked together.

One possibility is that the problem occurs when the action is evaluated to make the command an implicit dependency. And Steven sez, "... maybe we're tacking on the suffix and then doing the substitution, when we should be doing it in the opposite order for this case."

Has at least two workarounds, so not a high priority. Assigning to 'research' since we don't know what's going on; as soon as you do, bring it back to be re-triaged by setting the milestone back to '-unspecified-'.

gregnoel said at 2010-07-21 17:00:30

Bug party triage. Bump the priority of this issue.

[mwichmann]

Small update 14 years later... the original error message is back:

scons: *** AttributeError `'str' object has no attribute 'exe'' trying to evaluate `$HELLO.exe'

Do we know if this issue is broader than this example (i.e. was this "simplest reproducer of something that really happens" or does it only fail with an empty source list)? Because an empty source list doesn't make sense... and SCons making assumptions based on not having a source file seems bogus and we might be able to catch that case and UserError it. Same thing on Linux:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o hello
gcc: fatal error: no input files
compilation terminated.
scons: *** [hello] Error 1
scons: building terminated because of errors.

It's making the same assumption - use a C compiler to generate an executable from no sources - and then somehow actually issues the command, how did this task even get queued?

Meanwhile, it looks to me like the assessment that the subst is happening too late is on target: "$HELLO" should become hello first, then any tacking on of suffixes as it's turned into a target.

[mwichmann]

Even more amusing (was trying to convince myself that empty-source-list was not a significant factor:

$ cat SConstruct
env = Environment(TRG='target')
env.Program('${TRG}', hello.c)
$ scons -Q
NameError: name 'hello' is not defined:
  File "blah.blah/2404/SConstruct", line 2:
    env.Program('${TRG}', hello.c)

Absent some magical fix, is it worth saying somewhere "a construction variable cannot be used as a target name in a Builder call"?