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

Don't lose local-options help text #3686

Closed
mwichmann opened this issue Jun 4, 2020 · 2 comments · Fixed by #4388
Closed

Don't lose local-options help text #3686

mwichmann opened this issue Jun 4, 2020 · 2 comments · Fixed by #4388
Labels
args_and_options options processing, arguments, get/setoption and their relationshiop

Comments

@mwichmann
Copy link
Collaborator

mwichmann commented Jun 4, 2020

This is related to other recent activity (issue on help, plus doc updating activities) but wanted to document the case specifically rather than hijacking a different issue.

Help message handling is logically awkward:

  1. scons' own help text is always available with -H. It also provides the initial text used for the local help, which is displayed with the -h option, which is the same as --help.
  2. AddOption calls add to the local help, but not to the SCons help.
  3. First call to Help either rewrites the local help, or appends to it, depending on value of append kwarg
  4. Subsequent call to Help appends to local help, regardless of value of append
  5. the Variables object method GenerateHelpText requires an env to operate on but Variables is not environment-specific. Why is this?

Complaints:

  • If the first Help call did not append, the help text from AddOption is lost: it's dropped from local help, and was not added to SCons help.
  • Inconsistent interpretation of Help(msg, append=bool): caller-supplied append honored on first call, ignored otherwise; default value of append appears to flip, first call defaults non-appending, subsequent calls default appending
  • It should be possible to construct a local help message consisting of local options (AddOption) and local variables (aka: "help for project-specific command line usage"). It isn't, unless full SCons help is retained in the local help as well. That can well be too noisy for a project that adds a number of its own options.
  • Help generated by AddOption calls gets a section banner (Local Options) but command-line variables do not.
@mwichmann mwichmann added the args_and_options options processing, arguments, get/setoption and their relationshiop label Mar 20, 2021
@mwichmann
Copy link
Collaborator Author

This looks like it's about the same thing as #2356, which already had dupes.

@mwichmann
Copy link
Collaborator Author

Commented in #2356 on current prototype. That does not fix the last bullet in the complaint list - a banner for Variables, nor does it yet address the idea of being able to add help text for Aliases and have them appear in the Help output, which has been mentioned but doesn't yet have an issue.

mwichmann added a commit to mwichmann/scons that referenced this issue Aug 1, 2023
An additional keyword argument, "local_only", is now recorgnized
by Help(). If true, and "append" is True, then only project-defined
help messages are saved into the help text. That is, save help added
by calls to AddOption, but not SCons' own help, which is added
a different way.

Fixes SCons#2356
Fixes SCons#3686

Signed-off-by: Mats Wichmann <mats@linux.com>
mwichmann added a commit to mwichmann/scons that referenced this issue Aug 1, 2023
An additional keyword argument, "local_only", is now recorgnized
by Help(). If true, and "append" is True, then only project-defined
help messages are saved into the help text. That is, save help added
by calls to AddOption, but not SCons' own help, which is added
a different way.

Fixes SCons#2356
Fixes SCons#3686

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
args_and_options options processing, arguments, get/setoption and their relationshiop
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant