| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
We have copies of this module in several PIM repositories (kdepim-runtime,
kldap, kimap, libksieve...).
It's time to move it to ECM and get rid of these copies.
Reviewers: #kde_pim, vkrause
Reviewed By: #kde_pim, vkrause
Subscribers: #frameworks, #build_system
Tags: #frameworks, #build_system, #kde_pim
Differential Revision: https://phabricator.kde.org/D8790
|
|
Will initially be used by KMix.
Differential Revision: https://phabricator.kde.org/D7823
|
|
Summary:
Enables generation of QCH files during a normal build,
for documenting the public API of a library.
These macros are especially done with release builds in mind,
so distributed packages (like from Linux distributions) can
include QCH files matching the version of the library and will be
also automatically updated on new versions of the libary.
Next to that these macros also support linking between different
QCH files, so a subclass from another library for which there also
is a QCH file installed will be linked to the entry in that other
QCH file.
This inter-QCH linking is especially useful for libraries extending Qt,
where many of the used types are from Qt libraries. The macros
come with the needed information for Qt libraries prepared, so the
used Qt libraries just need to be listed in the LINK_QCHS argument
by target names, like Qt5Core_QCH or Qt5Widgets_QCH.
This should be a nice supplement to online services like api.kde.org,
like Qt's own QCH files are to doc.qt.io,
While QCH files from an abstract POV could be seen similar to code
libraries, being components with links to lookup symbols/entries in
other QCH files, so the rules and code should be done with similar
concepts, currently CMake's target system seems bound to executable
code creation. So things like "file(EXPORT ...)" could sadly not be
reused, as custom targets are not supported with that.
Thus a custom macro had to be created for now. Also could I not find
a way to use namespaces like KF5::, for more consistent target naming.
The patch also adds two variables to KDEInstallDirs.cmake for
controlling where the QCH (and respective doxygen tag files) are
installed. The QTQCHDIR variant allows to install QCH files for
Qt-extending libraries into the same folder where Qt's own QCH
files are, so Qt Assistant & other QCH viewer pick up them automatically
to add them to the default help file collection.
The QCHDIR variant would provide a neutral, but central installation
location. Neutral, as it never "pollutes" the Qt system dirs with files
possibly unrelated to Qt-based development (e.g. when simply using qthelp
tools for documentation), and central, to help with finding available QCH
files for manually adding/loading them into a viewer, given there is no
official way currently to register the availability of QCH files on
installing.
Open questions:
a) target system for exporting/importing done in a sane way?
Better name pattern for the QCH targets than xxx_QCH
(see the targets created for Qt, like Qt5Core_QCH)?
b) sharing metadata with kapidox
Initially I placed these macros into the kapidox module, as this seems the
logic place. And would match what kdoctools does for user manuals.
Just, that would create a build dependency on kapidox which complicates usage
a little. Having these macros in ECM delivers them with no extra effort
needed.
The data in metainfo.yaml is partially duplicated with the data feed into
the macros. How to deduplicate that is still open. Especially with the need
to not depend on external data sources like identify.kde.org.
Issues:
* doxygen versions before 1.8.13 are broken and miss to include some files
with generated QCH (https://bugzilla.gnome.org/show_bug.cgi?id=773693)
* Qt Assistant often only built with QTextBrowser, while doxygen uses lots
of HTML5 (incl. hardcoded JavaScript)
(https://bugzilla.gnome.org/show_bug.cgi?id=773715),
needs e.g. distributions to use QtWebKit to work, upcoming Qt versions
might soon also have QtWebEngine based help viewer
(https://codereview.qt-project.org/#/c/111559/)
* inter-QCH links do not work in KDevelop currently
(see https://bugs.kde.org/show_bug.cgi?id=372747) if installed as
separate QCH files
More details/background info at
https://frinring.wordpress.com/2016/09/27/adding-api-dox-generation-to-the-build-by-cmake-macros/
Tags: #frameworks, #build_system
Differential Revision: https://phabricator.kde.org/D2854
|
|
REVIEW: 128780
|
|
At least Okular and KBibTex include a FindPoppler.cmake module but this one
uses the new ECMFindModuleHelpers and has imported targets.
REVIEW: 126183
|
|
templates are very useful as teaching tool in order to make
a minimal application that uses a certain framework.
templates in the KAppTemplate repository will always get forgotten
(plus kapptemplate is not really necessary as they work in kdevelop as well)
An ideal situation would be frameworks having templates in their own repos
with templates of barebone apps using the main framework features.
In order to do that, the cmake stuff needed in order to correctly install
a template needs to be ported to a place avaiable to all frameworks
REVIEW:126185
|
|
It should now be easier to read, and more featureful. Among other
tweaks, we now print a summary of dependencies and build options, and
the documentation is generated with more sensible breadcrumbs and
builds properly with Sphinx 1.3.
REVIEW: 126075
|
|
This makes life a bit easier for developers who use the categorised
logging in Qt5 in the common case - rather than creating two new files,
and remembering to put in the #ifdef for the default verbosity settings
in Qt 5.4, they can just add a couple of lines to their CMakeLists.txt.
REVIEW: 124595
|
|
|
|
Three modules (ECMCoverageOption, ECMEnableSanitizers and
ECMGeneratePkgConfigFile) were not being documented. This commit fixes
that situation.
|
|
This is basically just the code available on the CMake FAQ item about
`make uninstall`, but packaged up in a convenient module.
REVIEW: 122359
|
|
This adds an application icon to an executable from PNG files for
Windows and Mac OS X. Unlike the similar kde4_add_app_icon macro from
kdelibs, this requires icons to be explicitly listed as arguments
(meaning CMake can tell when ones are added or deleted and reconfigure
as appropriate), and it works with Matthias Benkmann's png2ico tool, as
well as the KDE-Win tool of the same name.
Currently missing unit tests. Also completely untested (except that
`make test` runs on Linux, so there are no obvious syntax errors).
With thanks to Ralf Habacker for the inital work on porting
kde4_add_app_icon.
CHANGELOG: Add ECMAddAppIcon module to add icons to executable targets
on Windows and Mac OS X.
|
|
Add a couple of find modules for wayland-scanner and qtwaylandscanner.
These modules find the respective executables and create a target that
points to the executable.
Targets are respectively Wayland::Scanner and Wayland::QtScanner.
There are also macros to generate C protocols with wayland-scanner and
C++ wrappers with qtwaylandscanner.
REVIEW: 120034
|
|
add FindLibGit2.cmake + doc link
scripts tries to detect version not by pkgconfig to work on windows without pkgconfig, too
REVIEW: 120196
|
|
ecm_create_qm_from_po_files() was actually not very useful in practice.
So that is deprecated, to be removed before ECM 1.0.
Instead, the ECMPoQmTools provides several useful functions:
ecm_create_qm_loader() (which already existed in
ECMCreateQmFromPoFiles), ecm_process_po_files_as_qm() (which has the
same signature as gettext_process_po_files() from the FindGettext
module) and ecm_install_po_files_as_qm(), which is a convenience
function mostly for the benefit of KDE Frameworks (although potentially
useful for whatever other projects have the unusual requirement of a
Gettext translation workflow but no Gettext usage in the code).
NB: some clean-up to the documentation was done by Alex Merry
<alex.merry@kde.org> as part of this commit.
REVIEW: 117823
|
|
The ecm sphinx module occasionally tried to modify a list it was
iterating over, which is a Bad Thing and raised an exception on the
third or so time it was run without clearing the build directory.
|
|
REVIEW: 117780
|
|
ecm_dbus_add_activation_service() requires suffient knowledge of its
internals to use that replacing two lines with one seems silly.
In order to use it you have to know it behaves like configure_file()
(because you have to construct the file yourself), except that it also
installs it somewhere (for which you have to make sure
DBUS_SERVICES_INSTALL_DIR is defined before you use it, which is
certainly not a given for non-KDE projects). By this point, why not just
use configure_file() and install()? The DBUS_SERVICES_INSTALL_DIR
provided by KDEInstallDirs is all the magic you actually need, and if
that's explicit in the CMakeLists.txt file, it's a lot more obvious that
you should have it defined somewhere.
REVIEW: 117581
|
|
This adds an ecm-developer manual that replaces writing-find-modules.md
(a lot of which was upstreamed to CMake's own documentation). It also
adds introductory text to the ecm-*-modules manuals.
|
|
REVIEW: 117624
|
|
|
|
This is deliberately modelled very closely on CMake's documentation
system. It's a hefty patch, because it involved changing all the
documentation to be in reStructuredText format. I also cleaned up the
copyright/license statements at the same time.
Note that the find modules contain the full license, due to the fact
that ecm_use_find_module() copies them out of the ECM distribution.
|
|
This currently mostly contains macros for handling components;
FindWayland and FindXCB are ported to use this module, which comes with
various improvements for them.
REVIEW: 116653
|
|
|
|
REVIEW: 116025
|
