Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

abbreviations of AddOption options do not cause error #3653

Closed
mwichmann opened this issue May 15, 2020 · 0 comments · Fixed by #3784
Closed

abbreviations of AddOption options do not cause error #3653

mwichmann opened this issue May 15, 2020 · 0 comments · Fixed by #3784

Comments

@mwichmann
Copy link
Collaborator

mwichmann commented May 15, 2020

From Discord discussion,

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:

$ python ../../scripts/scons.py -Q --foobaz
Added opt: --foobar, dest=myfoo
GetOption('myfoo') returns False
usage: scons [OPTION] [TARGET] ...

SCons Error: no such option: --foobaz

Called with an abbreviation - neither recognized as foobar, nor flagged as unknown.

$ python ../../scripts/scons.py -Q --foo
Added opt: --foobar, dest=myfoo
GetOption('myfoo') returns False
scons: `.' is up to date.
mwichmann added a commit to mwichmann/scons that referenced this issue May 17, 2020
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.

Fixes SCons#3653

Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann added a commit to mwichmann/scons that referenced this issue Jun 1, 2020
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.

Fixes SCons#3653

Signed-off-by: Mats Wichmann <mats@linux.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant