Summary:
Avoids all the explicit boilerplate needed and allows
code reusing.
Depends on D10749
Test Plan:
Still builds, generated and installed CMake Config file works
as before.
Reviewers: #plasma, #frameworks
Subscribers: apol
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D11295
Summary:
automoc by itself can only detect metadata files referenced by direct
usage of the Q_PLUGIN_METADATA macro. It does not do any C++ preprocessor
evaluation. Instead it needs to be helped with regexp-based filter rules
for detecting any names of files used as additional moc input.
See docs for AUTOMOC_DEPEND_FILTERS for further details.
In the near future all the boilerplate code should be replaced with a yet to
be designed ECM macro. For now explicit code is used to collect use cases
for the macro and still to fix the issue already.
Test Plan:
Changing a JSON file (or for those generated from .desktop files
changing that one) and running make results in the related *.moc file
being regenerated and the related object file being recompiled.
qtplugininfo shows that the created plugin binary has up-to-date JSON
content.
Reviewers: #frameworks, #build_system, apol
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D10732
Using the new extra-cmake-modules module ECMAddQch (since 5.36.0)
this adds the option to automatically build and install a file
in QCH format with the docs about the public API, which then can be
used e.g. in Qt Assistant, Qt Creator or KDevelop.
Additionally the installed cmake config files will be extended
with a target KF5Plasma_QCH containing information about how to "link"
into the generated QCH file, which then can be used in the cmake build
system of other libraries building on this library, by
simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage.
And a respective doxygen tag file with all the metadata about the
generated QCH file and used for the "linking" will be created and
installed.
Pass -DBUILD_QCH=ON to cmake to enable this.
this ports most of libplasma away from sycoca, using instead
a combination of KPluginLoader and KPackage::PackageLoader instead
(so eventually using their own little caches instead of the
global sycoca cache)
a kservicetypetrader call is left in the loading of
containmentactions since is the only way to make an older
workspace still work, but is only a fallback, so containmentactions
in plasma-workspace can be ported eventually as well
Change-Id: Ie9579c3e01284f6d97043e22d01bbe63d3c3f45a
REVIEW:123626
since Plasma_INCLUDE_DIR doesn't seem to be used anywhere and fails on CI
experiment with removing it, to see if all packages depending from plasma
build
Change-Id: I1b8f99b0d7e9de2f33674646e273f141646eaeb2
Plasma::Package internally uses KPackage, being a pure wrapper.
old client code and old packagestructures still work using the wrapper.
old workspace code that is not directly using kpackage continues to work correctly
Change-Id: I05f95e8d05e3b67759973c4009e3753c61b1dcce
