aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorFriedrich W. H. Kossebau <kossebau@kde.org>2016-12-05 19:11:07 +0100
committerFriedrich W. H. Kossebau <kossebau@kde.org>2017-06-05 00:16:46 +0200
commitc837f58d505bfbfedb39288b839a62a6e9f1d1bf (patch)
tree6edfe68e8517d3470a3ffa033c3a41967b67dd4f /docs
parent5fa41ecd623da7f69061bc5091bd4a3006c9895b (diff)
downloadextra-cmake-modules-c837f58d505bfbfedb39288b839a62a6e9f1d1bf.tar.gz
extra-cmake-modules-c837f58d505bfbfedb39288b839a62a6e9f1d1bf.tar.bz2
New: ECMAddQch, for generating qch & doxygen tag files
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
Diffstat (limited to 'docs')
-rw-r--r--docs/module/ECMAddQch.rst1
1 files changed, 1 insertions, 0 deletions
diff --git a/docs/module/ECMAddQch.rst b/docs/module/ECMAddQch.rst
new file mode 100644
index 00000000..19fd2fd3
--- /dev/null
+++ b/docs/module/ECMAddQch.rst
@@ -0,0 +1 @@
+.. ecm-module:: ../../modules/ECMAddQch.cmake