COMMAND_LINE_TARGETS doesn't deal with option values

[bdbaddog]

This issue was originally created at: 2011-03-28 16:34:01.
This issue was reported by: stever_.

stever_ said at 2011-03-28 16:34:01

There seems to be an inconsistency in handling options that take values when they're specified without an '='. This seems to be caused by the loop in _main that assigns anything that doesn't start with '-' or have an '=' in it to COMMAND_LINE_TARGETS, rather than letting the option parser figure it out properly.

Here's an example SConscript:

import sys
 
AddOption('--option')
 
print('option:', GetOption('option'))
print('targets:', COMMAND_LINE_TARGETS)
 
sys.exit(0)
'''

And here's the problem:

% scons --option=FOO BAR
scons: Reading SConscript files ...
option: FOO
targets: ['BAR']
% scons --option FOO BAR
scons: Reading SConscript files ...
option: FOO
targets: ['FOO', 'BAR']

>ipatrol said this issue blocks #2763 at 2011-05-14 12:29:10.

[mwichmann]

I consider this to be the same issue as #2977. In basic terms, when the options are first parsed, the parser knows nothing about options added by AddOption. This makes sense: those aren't known until the sconscripts have been read, and since the starting SConstruct can come from a command-line option you have to look at the arguments first. What scons does is store away those options which aren't known, rather than throwing an exception; they are then reprocessed when AddOption calls are seen during sconscript processing. Unforturnately, only if the long-option --arg=foo form is used is there are single option word to store away and get it right. If the option and arg are space-separated only the option is stored away for later use; one (or more, in the case of nargs > 1) space-separated args cannot be known to belong to the option because we haven't seen the call to describe the added option yet, so they just get left on the list of extra args, which scons then takes as targets (thus how they end up on COMMAND_LINE_TARGETS)

[mwichmann]

See also #2805