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

Cleanup Argument parser. #3640

Merged
merged 10 commits into from
Mar 9, 2021
Merged

Cleanup Argument parser. #3640

merged 10 commits into from
Mar 9, 2021

Conversation

poelzi
Copy link
Contributor

@poelzi poelzi commented Feb 17, 2021

Use QCommandLineParser instead of buggy hand crafted one.

Use QCommandLineParser instead of buggy hand crafted one.
@Be-ing
Copy link
Contributor

Be-ing commented Feb 17, 2021

Scanning dependencies of target mixxx-benchmark
[100%] Mixxx Benchmarks
Unknown option 'benchmark'.
CMakeFiles/mixxx-benchmark.dir/build.make:57: recipe for target 'CMakeFiles/mixxx-benchmark' failed
make[3]: *** [CMakeFiles/mixxx-benchmark] Error 1
CMakeFiles/Makefile2:1427: recipe for target 'CMakeFiles/mixxx-benchmark.dir/all' failed
CMakeFiles/Makefile2:1434: recipe for target 'CMakeFiles/mixxx-benchmark.dir/rule' failed
make[2]: *** [CMakeFiles/mixxx-benchmark.dir/all] Error 2
Makefile:730: recipe for target 'mixxx-benchmark' failed
make[1]: *** [CMakeFiles/mixxx-benchmark.dir/rule] Error 2
make: *** [mixxx-benchmark] Error 2
Error: Process completed with exit code 2.

???
seems unrelated to the changes in this branch... did Google Benchmark break?

@poelzi
Copy link
Contributor Author

poelzi commented Feb 17, 2021

@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.

@poelzi
Copy link
Contributor Author

poelzi commented Feb 17, 2021

@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.

@poelzi
Copy link
Contributor Author

poelzi commented Feb 17, 2021

ready for review. There is one thing I could not fix, in the shell calling
"--settingsPath=~/blubb" does not work while "--settingsPath ~/blubb" does.
Using an absolute path always works, but in later case, the shell properly expands ~ in the first case it does not. Since I found no easy way to expand ~ in Qt, I accepted the case ;)

Copy link
Contributor

@uklotzde uklotzde left a 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.h Outdated Show resolved Hide resolved
parser.addOption(locale);

// An option with a value
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"),
Copy link
Member

@Holzhaus Holzhaus Feb 22, 2021

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.

Suggested change
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"),
const QCommandLineOption settingsPath(QStringLiteral("settingsPath"),

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

src/util/cmdlineargs.cpp Outdated Show resolved Hide resolved
src/util/cmdlineargs.cpp Outdated Show resolved Hide resolved
src/util/cmdlineargs.cpp Outdated Show resolved Hide resolved
Comment on lines +65 to +66
"https://manual.mixxx.org/2.3/chapters/appendix.html#command-line-options).\n"
"CamelCase arguments are deprecated and will be removed in 2.5"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"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.

@Be-ing
Copy link
Contributor

Be-ing commented Mar 3, 2021

Wait, are we removing the camelCase versions now or not?

@poelzi
Copy link
Contributor Author

poelzi commented Mar 3, 2021

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.
2.3 and the version here does not exit on wrong arguments but silently ignores them.
Should I change it, that unknown arguments cause an error ? (then I need to add a hidden --benchmark argument for the tests).

@uklotzde
Copy link
Contributor

uklotzde commented Mar 3, 2021

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.

Good point, I didn't consider this use case. Then a version with both variants available makes sense.

@Holzhaus
Copy link
Member

Holzhaus commented Mar 3, 2021

2.3 and the version here does not exit on wrong arguments but silently ignores them.
Should I change it, that unknown arguments cause an error ? (then I need to add a hidden --benchmark argument for the tests).

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.

@Be-ing
Copy link
Contributor

Be-ing commented Mar 3, 2021

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.

@Be-ing
Copy link
Contributor

Be-ing commented Mar 3, 2021

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.

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.

Copy link
Contributor

@Be-ing Be-ing left a 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.

@Holzhaus
Copy link
Member

Holzhaus commented Mar 7, 2021

There's still an unresolved review comment from you above.

@Be-ing Be-ing merged commit e6ec561 into mixxxdj:main Mar 9, 2021
@Holzhaus
Copy link
Member

Holzhaus commented Mar 9, 2021

There's still an unresolved review comment from you above.

I guess your review comment was irrelevant then?

@Be-ing
Copy link
Contributor

Be-ing commented Mar 9, 2021

It can be fixed in another PR.

@daschuer
Copy link
Member

This messes up the --help console output
I have filed a bug: https://bugs.launchpad.net/mixxx/+bug/1926126

@poelzi
Copy link
Contributor Author

poelzi commented Apr 26, 2021

@daschuer on which system type? Because I checked this on linux and had no such issue.

@daschuer
Copy link
Member

I am on Ubuntu Focal
grafik

@poelzi
Copy link
Contributor Author

poelzi commented Apr 26, 2021

Interesting. It looks like this here:
Screenshot_20210426_114931

@poelzi
Copy link
Contributor Author

poelzi commented Apr 26, 2021

Is it the argument list that moves the description so much to the right ?
Maybe a qt version difference ? I'm using qtbase-5.15.2

@daschuer
Copy link
Member

I think it is because you are not using the terminal default width of 80.

@poelzi
Copy link
Contributor Author

poelzi commented Apr 26, 2021

QT is pretty stupid when formatting the help text
https://github.com/qt/qtbase/blob/101581484bd278ce4a5f329ffb13c9e0b0e4c131/src/corelib/tools/qcommandlineparser.cpp#L1123

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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants