D7216: refactor kpackagetool away from stringy options

[Harald Sitter]

sitter created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION 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

REPOSITORY
  R290 KPackage

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D7216

AFFECTED FILES
  src/kpackagetool/kpackagetool.cpp
  src/kpackagetool/main.cpp
  src/kpackagetool/options.h

To: sitter, sebas, apol
Cc: #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170809/e2608207/attachment.html>