The `CMAKE_INSTALL_DATAROOTDIR` variable might be overridden by the project
to point to some custom location (e.g. `share/games` instead of `share`)
but this doesn't mean we will be able to find icons there.
Since icons are almost always under `/usr/share/icons` it makes sense to
add that location as one last hard-coded fallback to avoid having to
specify `BUILTIN_ICON_THEMES_SEARCH_PATH` in that common case.
The web view is only an optional enhancement in my applications so having
the support disabled is rather common. So for a better out-of-the-box
experience when configuring my projects it makes sense not having to
disable web view support explicitly if Qt WebEngine is not installed
anyways.
* Set the default icon theme when applying Qt settings and the "system"
theme is supposed to be used but none could be determined by Qt
* Use a bundled icon theme depending on whether the current palette is
light or dark
* Apply the default not only under Windows anymore; supposedly this makes
sense under any platform where Qt cannot determine the icon theme for us
* Detect a static Qt build and link against Qt plugins automatically in
that case (without the necassity to set `STATIC_LINKAGE`)
* Add offscreen support on UNIX platforms as it is useful for testing on
headless systems
* Add wayland support if available
* Populate `QT_TEST_LIBRARIES` in case we're not building an app because
the plugins are still required when building tests
In the "normal" case none of the other variables are set
and thus relative paths (e.g. for the plugin directory)
cannot be resolved. This should still work when
CMAKE_FIND_ROOT_PATH is set beause we still check within
the other locations.
This Qt release "pluginized" the backends for TLS support so we need to
make sure to link against at least one TLS plugin since all of my
applications which use Qt Network expect TLS to work.
When cross compiling with Qt 5 the QT_HOST_PATH variable might
be set as well but the module might not be installed within the
host path. So let's do the usual lookup first and fallback to
QT_HOST_PATH only if that doesn't work.
The variables provided by Qt 6 might just contain a relative path. This
change adds an extra function resolve these via CMAKE_PREFIX_PATH and
CMAKE_FIND_ROOT_PATH.
In Qt 5 these plugins were loaded as part of the Svg module (at least with
my patches). With Qt 6 (for which I've dropped my patches) we need to
include the plugin's config file manually.
* Making an Android APK should now generally work with NDK r21.d and
Qt 5.15.1 and CMake 3.18 although some details might still need tweaking
* It is now supposed to be used within the NDK's toolchain instead of
CMake's built-in Android support (which makes problems with newer NDK
versions)
* The old way to lookup/pass variables is preserved so it should still
work with older Qt versions and CMake's built-in Android support
* Qt's own support for invoking androiddeployqt needed to be disabled
because it lead to CMake errors (see comment)
Martchus