-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Cleanup Argument parser. #3640
Cleanup Argument parser. #3640
Conversation
Use QCommandLineParser instead of buggy hand crafted one.
471771e
to
1fa364f
Compare
??? |
@Be-ing no, the problem was that I used process which will fail on unknown parameters and the benchmark will pass --benchmark. I changed that unknown parameters are not fatal anymore. |
@Be-ing the alternative would be to add --benchmark as a hidden parameter. This way unknown arguments would rise an error again. Personally, I don't care, we ignored unknown paremeters before, so the behaviour is like before. |
ready for review. There is one thing I could not fix, in the shell calling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanup. Changes look reasonable, have not tested it yet.
Any other opinions? Otherwise, please merge.
src/util/cmdlineargs.cpp
Outdated
parser.addOption(locale); | ||
|
||
// An option with a value | ||
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to get rid of these weird camelCase command line args and use names like --fullscreen
and --settings-path
instead. Out of scope for this PR though.
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"), | |
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added non camecase versions and added a comment that CamelCase arguments will be removed in 2.5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with removing the camelCase versions for 2.4. I don't think there's any particular reason to delay that another release. What do others think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's clean it up now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think it would be likely to be forgotten or procrastinated on finishing if we don't do it now.
"https://manual.mixxx.org/2.3/chapters/appendix.html#command-line-options).\n" | ||
"CamelCase arguments are deprecated and will be removed in 2.5")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"https://manual.mixxx.org/2.3/chapters/appendix.html#command-line-options).\n" | |
"CamelCase arguments are deprecated and will be removed in 2.5")); | |
"https://manual.mixxx.org/2.4/chapters/appendix.html#command-line-options")); |
Please make a PR for the manual too.
Wait, are we removing the camelCase versions now or not? |
The reason I would like to have them stick around for a version is that I don't need 2 different argument versions when running 2.3 and 2.4 in parallel. I don't want to accidentally use the wrong settings folder all the time when testing a 2.3 branch. |
Good point, I didn't consider this use case. Then a version with both variants available makes sense. |
Yes, I think showing an error is almost always preferable to silently ignoring them (except for special cases, e. g. during live use). However, I fear it's not that simple because there are a lot more arguments that we'd need to handle because we use the argument parser for the tests binary, too. So we would need to add every single command line flag added by gtests. Therefore I think we should postpone that for another PR and maybe add a special argument parser that only supports setting the log level and does ignore unknown flags for tests only. |
Looking at the code, the cost of keeping the camelCase variants is trivial; it is just adding another string literal to a QStringList. So I don't think there's any urgent reason to remove them. |
Good point. This won't be an issue for switching between 2.4 and 2.5 because both will support the new style options. So I think we should stick with the original plan to keep the camelCase versions for 2.4 and remove them for 2.5. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there are no objections, I'll merge this tomorrow.
There's still an unresolved review comment from you above. |
I guess your review comment was irrelevant then? |
It can be fixed in another PR. |
This messes up the --help console output |
@daschuer on which system type? Because I checked this on linux and had no such issue. |
Is it the argument list that moves the description so much to the right ? |
I think it is because you are not using the terminal default width of 80. |
QT is pretty stupid when formatting the help text I will try splitting the obsolete versions into extra options without help, but I guess as long as we have multiple long versions, it will always look this bad :( |
Use QCommandLineParser instead of buggy hand crafted one.