BUG: 389519

For locales like de_AT, the current code only looks in
share/locale/de_AT/ and share/locale/de-AT/ for translation catalogs,
but not in share/locale/de/ where they most likely are.
That's because bcp47Name() returns "de-AT" for de_AT (though in the
case of de_DE e.g. it does return "de").

This patch additionally tries to fall back to the general language by
taking the part of the locale name before the first '_'.

Differential Revision: https://phabricator.kde.org/D9793

Summary:
We were using a link.txt file that cmake used to generate, on newer cmake
versions it doesn't anymore.
Instead use readelf, much like androiddeployqt does, to extract the
depenencies.
Catch: It relies on having all the binaries being at the same subdirectory,
which is the default in ECM since not long ago.

Test Plan: Build kirigamigallery with it

Reviewers: #frameworks, #build_system, aacid

Reviewed By: aacid

Subscribers: mart

Tags: #frameworks, #build_system

Differential Revision: https://phabricator.kde.org/D8173

Summary:
pkgconfig complains when the .pc file doesn't have a description. eg:
$ pkg-config Baloo
Package 'Baloo' has no Description: field

With this change, if the DESCRIPTION parameter is not used,
ECM_GENERATE_PKGCONFIG_FILE will :
- First look if there's a metainfo.yaml file and get the description from there
- If the file doesn't exist, or if the description tag is empty or non-existent,
create a description based on the LIB_NAME value

Test Plan: Tests added & pass

Reviewers: dfaure, apol

Reviewed By: dfaure

Subscribers: #frameworks, #build_system

Tags: #frameworks, #build_system

Differential Revision: https://phabricator.kde.org/D9056

Summary:
Allows to check if a module is available on the system and sets it as a
runtime dependency.
This is useful for projects so that they can specify their qml dependencies
easily and packagers and developers get to see what's missing by looking
at the cmake output.

Reviewers: #build_system, #frameworks, sitter

Reviewed By: sitter

Subscribers: dfaure, aacid

Tags: #frameworks, #build_system

Differential Revision: https://phabricator.kde.org/D7094

Currently the test still passed even if one of the check_translations()
calls would fail.
The reason is that check_translations() is a function which has its own
scope, so if it sets "failed" the upper level doesn't see it.

Use the PARENT_SCOPE option when setting the variable to properly
propagate the value to the upper level.

Differential Revision: https://phabricator.kde.org/D6701

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

when checking whether there were new sources added (on Windows and Mac),
check whether the variable is empty as list, instead of failing because
of a cmake syntax error