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 KF5Config_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.
Summary:
When using a toolchain file one often would want to set a
CMAKE_FIND_ROOT_PATH to "re-root" lookups into a staging area to prevent
native host artifcats from being found. This in particular is usually the
case for lib/include/package finders as one would want the target
systems build artifacts rather than the hosts.
find_file() unfortunately draws its re-rooting rule from
CMAKE_FIND_ROOT_PATH_MODE_INCLUDE, which as mentioned would usually be
set not to look in the actual host paths to avoid picking up wrong includes
which would also prevent find_file to work here.
In the case of the coreaddonstooling it makes sense to look in the host
though. For one the lookup only runs when CROSS_COMPILING is set (which
usually is the case for toolchains), AND one explicitly has to specify a
HOST_TOOLING path. So in a way by specifying that one is already opting
out of whatever rooting rules one has set elsewhere as setting that var
is a clear indication that we have *specific* host tooling and we want
to use that rather than anything else.
As a result NO_CMAKE_FIND_ROOT_PATH is the way to go when looking for stuff
under a KF5_HOST_TOOLING conditional.
Reviewers: mdawson, apol
Reviewed By: apol
Subscribers: #frameworks
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D5218
This way we can specify the used tooling targets to be used, useful if we're
cross-compiling, since we get to use the tooling that runs in the local
platform.
REVIEW: 124104
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, kdelibs frameworks branch, at commit
162066dbbecde401a7347a1cff4fe72a9c919f58
Friedrich W. H. Kossebau
Harald Sitter
Sven Brauch
Aleix Pol
Alex Merry
Jenkins CI