You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in the manpage and in the code in SCons/Script/SConsOptions.py, options added via AddOption are taken literally, abbreviations of the long option names do not work, unlike the optparse add_option, where abbreviations are accepted. This is for sequencing reasons: the list of remaining options is reparsed every time a call to AddOption is seen, because SCons wants to allow the user to immediately call GetOption in the same sconscript to fish out a possible value for that option. In this scenario you cannot accept --foo as an abbreviation for --foobar, because you don't yet know if --foo will be a unique abbreviation - perhaps later an AddOption would define a --foobaz option (in which case foo is no longer unique), or even --foo itself.
SCons does indeed not recognize abbreviations as synonyms for an AddOption option, but, it also doesn't say anything about them. As per the discussion, this has been seen in the field, where leaving off the final 's' off an option led to behavior surprising because there was no error indicating this option was unrecognized.
Simple illustration - SConstruct:
AddOption('--foobar',
dest='myfoo',
action='store_true',
default=False,
help='Supply a silly option for testing'
)
opt = GetOption("myfoo")
print(f"GetOption('myfoo') returns {opt}")
Called correctly (the "Added opt" line is debugging from a custom scons version, just for illustration):
$ python ../../scripts/scons.py -Q --foobar
Added opt: --foobar, dest=myfoo
GetOption('myfoo') returns True
scons: `.' is up to date.
Called with an unknown argument generates an error, as expected:
Adds a post-processing step called after sconscript processing
is done which checks if there are any leftover options. Previously,
some options would sneak through silently if they were an
abbreviation of another option added by AddOption.
FixesSCons#3653
Signed-off-by: Mats Wichmann <[email protected]>
Adds a post-processing step called after sconscript processing
is done which checks if there are any leftover options. Previously,
some options would sneak through silently if they were an
abbreviation of another option added by AddOption.
FixesSCons#3653
Signed-off-by: Mats Wichmann <[email protected]>
From Discord discussion,
As mentioned in the manpage and in the code in
SCons/Script/SConsOptions.py
, options added viaAddOption
are taken literally, abbreviations of the long option names do not work, unlike the optparseadd_option
, where abbreviations are accepted. This is for sequencing reasons: the list of remaining options is reparsed every time a call toAddOption
is seen, because SCons wants to allow the user to immediately callGetOption
in the same sconscript to fish out a possible value for that option. In this scenario you cannot accept--foo
as an abbreviation for--foobar
, because you don't yet know if--foo
will be a unique abbreviation - perhaps later anAddOption
would define a--foobaz
option (in which case foo is no longer unique), or even--foo
itself.SCons does indeed not recognize abbreviations as synonyms for an
AddOption
option, but, it also doesn't say anything about them. As per the discussion, this has been seen in the field, where leaving off the final 's' off an option led to behavior surprising because there was no error indicating this option was unrecognized.Simple illustration -
SConstruct
:Called correctly (the "Added opt" line is debugging from a custom scons version, just for illustration):
Called with an unknown argument generates an error, as expected:
Called with an abbreviation - neither recognized as foobar, nor flagged as unknown.
The text was updated successfully, but these errors were encountered: