Review Request 128590: Let kpackagetool5 generate appstream information for kpackage components

[Aleix Pol Gonzalez]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128590/
-----------------------------------------------------------

Review request for KDE Frameworks, Plasma, Matthias Klumpp, and Harald Sitter.


Repository: kpackage


Description
-------

We want our components to be exposed on software using Appstream (such as Discover, but not exclusively). Some of the most hidden components we have nowadays are Plasma addons, since they're not documented there. This attempts to fix this by reusing the metadata we already have and turning it into files that appstream can consume, without having to write yet another time the plugin metadata.

This is done in 2 steps:

* Introduces `kpackagetool5 --appstream-metainfo` argument
* The cmake macro will automatically grab the file and process it. See: https://git.reviewboard.kde.org/r/128579/


Diffs
-----

  KF5PackageMacros.cmake 9163de9 
  autotests/CMakeLists.txt c84379d 
  autotests/data/testfallbackpackage/testfallbackpackage.appdata.xml PRE-CREATION 
  autotests/data/testpackage/testpackage.appdata.xml PRE-CREATION 
  autotests/kpackagetoolappstreamtest.cmake PRE-CREATION 
  src/kpackagetool/kpackagetool.h dc056c6 
  src/kpackagetool/kpackagetool.cpp 2758f70 
  src/kpackagetool/main.cpp a8eb5ab 

Diff: https://git.reviewboard.kde.org/r/128590/diff/


Testing
-------

Tests pass, everything else still compiles (including r128579), we get quite some metadata.
`appstreamcli validate` doesn't choke on output files.


Thanks,

Aleix Pol Gonzalez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160803/ba33f4b8/attachment-0001.html>