Only use plugin finalizer mode if qt_finalize_target is called at the
end of the user project (which we can't really check, the user has to
ensure that) or when qt_finalize_target is automatically defer-called
by CMake 3.19+ (which is done by qt_add_executable).
This removes the previous behavior of using the finalizer mode if
qt_import_plugins is called. Instead the old regular mode is used
if the above preconditions are not met.
The removed behavior had ordering issues if qt_import_plugins was called
before target_link_libraries. The dependency walking would be done
before Qt dependencies were added and thus no plugins would be
linked.
Amends 6fcc272ac9
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Task-number: QTBUG-94030
Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It's very likely that we'll have to run certain finalizer code for
targets other than executables.
Rename qt_finalize_executable to _qt_internal_finalize_executable so
it's internal.
Introduce a new function qt_finalize_target which will call the above
internal one when the target is an executable.
This should future proof the API so we have a hook to call code for
any user CMake project that intends to use Qt CMake API.
Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Allow linking all plugin initializer object libraries directly
into the final target (executable or shared library).
The finalizer mode is triggered when the project adds a call
to qt_import_plugins, as well when the project has an explicit
call to qt_finalize_executable or when it is defer called by
CMake 3.19+.
Otherwise the old non-finalizer mode is used, where each plugin
initializer object library is propagated via the usage
requirements of its associated module.
A user can explicitly opt in or out of the new mode by calling
qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE)
The implementation, at configure time, recursively collects all
dependencies of the target to extract a list of used Qt modules.
From each module we extract its list of associated plugins and
their genex conditions. These genexes are used to conditionally
link the plugins and the initializers.
Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the
property even on INTERFACE libraries with lower CMake versions.
QT_PLUGINS is kept for backwards compatibility with projects already
using it, but should be removed in Qt 7.
The upside of the finalizer mode is that it avoids creating link
cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to
duplicate the library on the link line, slowing down link time as well
as possibly breaking link order dependencies.
The downside is that finalizer mode can't cope with generator
expressions at the moment. So if a Qt module target is wrapped in a
generator expression, it's plugins will not be detected and thus
linked.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Now that we run tests for static Qt builds in the CI, it makes sense
to restore the CMake build tests that check that static plugin
importing works correctly.
Resurrect the previously commented out test_import_plugins project and
port the mockplugins qmake projects to CMake.
mockplugins is a CMake project that uses the internal Qt CMake API to
build and install some Qt modules and plugins.
test_import_plugins depends on that test (via a CMake fixture) to
build public projects that use those plugins.
The installation of the mockplugins modules pollutes the Qt install
prefix, but in the CI that only happens on the test VM, which means
the release packages are not affected.
Locally on a developer machine the Qt install path will be polluted,
but it's not that much of a big deal. We could try and address that in
a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH
functionality added for Conan to allow the installation of Qt packages
into a non-standard prefix.
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This commit adds transitive dependencies to the plugins, so that a
sane set of default plugins get auto-imported when linking against a
module. It also provides a new function, qt5_import_plugins(), which
allows you to override the set of plugins that get imported. The decision
of whether or not to import a specific plugin is based on several custom
target properties and a very clever generator expression.
Note that this change only imports plugins on static Qt builds. It
does nothing on shared Qt builds, as the shared libraries already have
their own plugin import mechanism.
[ChangeLog][CMake] Added ability to auto-import non-qml plugins on
CMake builds
Task-number: QTBUG-38913
Task-number: QTBUG-76562
Change-Id: I2d6c8908b521cf6ba1ebbbc33a87cb7ddd9935cf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
