refactor kpackagetool away from stringy options

Authored by sitter on Aug 9 2017, 1:23 PM.

Description

refactor kpackagetool away from stringy options

Summary:
A notable advantage of qcommandlineoption is that using the objects the
compiler makes sure that everyone is talking about the same option.
Previously kpackagetool would create the option objects in main but then
not use them to grab values out of the commandlineparser, instead relying
on the stringy representation of the option. This is a tad harder to
read but more importantly, it bypasses the compiler opening the code up for
typos. Namely one could do d->parser->value("hahs") while doing
d->parser->value(Options::hahs) will result in a build failure.

To preven this, refactor the entire option handling to use static option
instances from a new Options namespace as to let the compiler help us not
write typos.

In the future option handling could be additionally changed to parse all
options at once early on and construct an option struct or something to
reduce code clutter from calling isSet a million times.

Test Plan:

  • all existing tests pass
  • --help still looks correct

Reviewers: sebas, apol

Reviewed By: apol

Subscribers: Frameworks

Tags: Frameworks

Differential Revision: https://phabricator.kde.org/D7216

Details

Committed
sitterSep 1 2017, 12:16 PM
Reviewer
apol
Differential Revision
D7216: refactor kpackagetool away from stringy options
Parents
R290:35af225e83e3: SVN_SILENT made messages (.desktop file) - always resolve ours
Branches
Unknown
Tags
Unknown