TL;DR: This creates two changes:
1. Makes the plugin inclusion status more visible for builders for both Qt
itself and applications.
2. Allows a simple patch-point for distros to change the default
(perhaps not ideal, but good enough).
3. Does not changes the current behavior.
As discussed both in the mailing list and privately with
Alexandru Croitor and Joerg Bornemann this makes a lot os sense for Qt
on static builds and when trying to find where the plugins are so they
can be easily packaged up in order to distribute a build with all the
dependencies on it.
But at the same time it makes no sense for distributions building the
libraries in dynamic mode as it forces unnecesary build time
dependencies for for both Qt and applications like QML modules or even
PostgreSQL! [0].
[0] <https://sources.debian.org/src/martchus-qtutilities/6.10.0-1/cmake/modules/QtConfig.cmake/?hl=35#L35>
Other approaches have been considered like not shipping specific CMake
files, but this depends on the packager finding the right ones at the
right time, and does not allows end users to change the behavior if they
happen to need it.
Change-Id: Id32fbc0cf0f289edd4426fb703cf1195288aacb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously QtModulePlugins.cmake files were only created and
included in static library Qt builds.
Having the targets available in shared library builds would be
useful for custom project deployment purposes. One could query
the location of the plugins or use various generator expressions
referencing their location.
Ensure we always generate and include the QtModulePlugins.cmake files
regardless of the build type.
Allow opting out of including the files by setting
QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml
plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION.
Pick-to: 6.4
Fixes: QTBUG-94066
Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Don't duplicate the logic of plugin package inclusion for each Qt
module. Instead move it into QtPublicPluginHelpers.cmake.
Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I5e1f5176a0e754ed56a792c97865752529462617
Reviewed-by: Jörg 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>
Extract common static plugin handling functionality into a separate
QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package.
Split the code into smaller functions that will be re-used by each
templated QtPlugins.cmake.in file, rather than copy pasting the same
code into each QtFooPlugins.cmake file.
As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake
as public helper files just like QtPublicPluginHelpers.cmake.
This makes it clearer that the functions are available outside
the internal Qt build and also provides a way for not dumping new
helper functions into Qt6CoreMacros.cmake.
Task-number: QTBUG-92933
Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building and installing a Qt repo that provides plugins for a Qt
module within a different repository (for example, qtimageformats
providing imageformat plugins for QtGui), re-configuring that repository
would result in configuration errors like
"add_library cannot create ALIAS target "Qt6::QTgaPlugin" because
another target with the same name already exists."
This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled
in the Qt6*PluginConfig.cmake files that create imported targets for the
plugins we want to build.
To fix this, when building Qt, we now load only plugins that are
provided by repositories the currently building repository depends on.
We read the repo dependencies from dependencies.yaml when the
Qt6BuildInternals package is loaded, but only in static builds and only
if we're currently building a Qt repository.
To find out whether we're building a Qt repository, we check whether
QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT,
because that variable is not available for the first find_package calls
in the repository's top-level project file.
In each Qt6*PluginConfig.cmake file, we bail out if the plugin's
repository is not one of the ones in QT_REPO_DEPENDENCIES.
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In static builds, we cannot allow any part of the main build to make a
call to find_package(Qt6...) where such a call may load a
Qt6*Plugins.cmake file. That would add additional dependencies to the
main module targets, setting up a circular dependency in the set of
*Config.cmake files which cannot be resolved. This scenario would be
triggered by per-repo builds or user projects.
But Qt's tools and other executables still need to load some plugins
in static builds. Sometimes a platform plugin may be enough, other
times we may want all supportable plugins (e.g. Qt Designer).
Therefore, add all plugins we can identify as relevant for an
executable that is part of the Qt build, but add them directly to the
executable without affecting the linking relationships between the
main module libraries.
Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in
top level builds because there should be no difference between per-repo
and top level builds any more (as far as linking static plugins is
concerned).
Examples that build as part of the main build will still build
successfully after this change, but they will not run if they require
a platform plugin. Examples need to be moved out to a separate build
where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS
set to TRUE to be runnable (see QTBUG-90820).
Fixes: QTBUG-91915
Pick-to: 6.1
Change-Id: I8088baddb54e394ca111b103313596d6743570ba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The $<NOT:...> genex already guarantees to return a value of 0 or 1,
so there's no need to wrap it with $<BOOL:...>.
Pick-to: 6.0 6.1
Change-Id: Iff4ad64ed8deaa846e1b5bc22d2e5d9dbcd77cc7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A call to file(WRITE) will unconditionally update the file's timestamp
even if the file's contents don't change. The *Plugin.cpp file was
being written using configure_file() which avoids that, but the .cpp.in
file it was configuring from was being written out using file(WRITE)
every time CMake ran. Autogen saw that file as a dependency and then
regenerated the mocs_compilation.cpp file, which in turn results in
unnecessary rebuilds and relinking when nothing is actually changing.
The file(WRITE) - configure_file() dance is no longer needed anyway,
since the generated *Plugin.cpp file is very simple with no
substitutions required. Therefore, we can simplify that file's
generation with a single file(WRITE) that only executes if the file
contents will change or the file is missing.
Pick-to: 6.1 6.0
Change-Id: I2b7d1ff678b85ea7811969d656555592c9b6865f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In static per-repo builds, we have a mix of targets provided by
packages and targets provided by the main build. For the builds that
create the packages, we must avoid adding a dependency for the main
module library target on its associated plugin targets or else the
package config files end up with a cyclic dependency that cannot be
resolved when something tries to consume them. This only happens for
static builds because we have been attaching a linking relationship
to the main module library that isn't really a true dependency, we
attached it only for convenience of things linking to that module
library.
To preserve that convenience linking without breaking the config
packages, we use the QT_NO_CREATE_TARGETS condition to prevent CMake
seeing that relationship when generating the *Config.cmake files.
Creating these relationships will be delayed until the plugin's
*Config.cmake file is loaded, at which point it will add itself to
the main module library's imported target INTERFACE (this was already
done before, we just now rely solely on that).
Task-number: QTBUG-90819
Pick-to: 6.1
Change-Id: Id725742182bcda64841be84fe1650bafb9151bb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit d0071a4f87 broke static top-level builds:
CMake Error at .../qtbase/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake:17 (set_property):
set_property can not be used on an ALIAS target.
Fixed by moving the un-aliasing of the target before the set_property
call.
Pick-to: 6.0
Change-Id: I96c731353798a58ff9b3a664f3614ef03c897dcb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Projects may call find_package(Qt6 ...) multiple times. When enabling
examples and tests, this happens a lot. For a statically built Qt,
for modules that have plugins (e.g. Gui), every time the module's
config file was loaded, it was generating and adding another copy of
the import plugin sources to the module target. These accumulated and
created many duplicates, which in turn blew out generation time and
made the build very inefficient.
This change checks whether the import plugin sources have already been
processed for the module target and ensures they are only added once.
It records its status on the target itself so that both local and
global targets are supported.
Fixes: QTBUG-90465
Change-Id: I1f45b1ee771a933ee755d44f1e983d6d9113dad0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This property is dynamically determined and set in the
Qt6${module-name}PluginsConfig.cmake files now.
There is no need anymore to export this property.
Change-Id: I2d164864c4099034b88f9ad852eae8b9f9e55f8b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When doing a per-repository build of Qt, as it is done for the installer
packages, the build of qtbase has no knowledge of plugins that might be
built and installed from other repositories. That means we must not
write a fixed list of known plugins when exporting Qt modules of qtbase.
In particular, qtsvg adds imageformat plugins that are supposed to be
picked up by qtbase's QtGui module when linking a project against a
statically linked Qt.
${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the
include statements for qtsvg's plugin config files and operated on a
fixed list of plugins, all from qtbase.
Apart from that, the Qt6::Gui target's property QT_PLUGINS did only
contain the qtbase plugins.
This patch fixes the situation in the following way:
1. All Qt6*PluginConfig.cmake files in
${install-prefix}/lib/cmake/Qt6Gui are detected and included.
2. From those file names, the target names of the plugins are
deduced. This is safe as the file name of those generated files is a
direct result of the plugin's target name.
3. The QT_PLUGINS property of the module is updated with the detected
plugin target names.
Fixes: QTBUG-89643
Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Static Qt plugins should not be included in the list of libraries of
a prl file. They end up being there due to our circular dependency
trick where the plugins depend on the module they belong
to.
This in turn causes the giant static plugin generator expressions to
be processed in qt_collect_libs(), and the generated prl file ends up
having target names like Qt6::QJpegPlugin which are obviously not
linker flags.
To eliminate the static plugins from prl files, add an additional
dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>'
that always evaluates to true. We can string match on this expression
in qt_collect_libs, and thus remove the whole static plugin genex
entry.
This should fix linking of apps with qmake that use a CMake-built
static Qt.
Task-number: QTBUG-85865
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
QtPlugins.cmake.in uses file(GENERATE) and target_sources() to
propagate the generated cpp files which contain plugin initialization
code to their consuming targets.
Unfortunately due to a bug in CMake, if the file is generated in a
different scope than the consuming target, the CMake generation
step will fail saying that the source file can not be found.
See https://gitlab.kitware.com/cmake/cmake/issues/18399 for details.
In the case of qtdeclarative, find_package(Qt6) is called at the top
level scope (this is when the file gets generated),
but the targets are created in subdirectory scopes, and the GENERATED
source file property is not propagated across scropes.
Circumvent the issue by instead using file(WRITE) and configure_file()
which create the file at configure time rather than generate time.
This will pollute the current binary directory with some more files,
but at least successfully fixes the build.
Change-Id: I3ab3b12dcbf6a9d0ab9ee87173e4a1952325b37b
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Some work was needed to make the plug-in types,
and which plug-ins are available for each type
in client code.
Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
The build failed due to two different reasons.
We tried to assign properties on an aliased target, which does not
work. Make sure to set properties on the original unaliased target.
We tried to query for the value of the QT_DEFAULT_PLUGINS property
when automatically linking to plugins, but the generator expression
failed in the AND section, because querying for an unexisting value
does not return an integer, and the AND expression expects an integer.
The fix is to wrap the relevant expression in a BOOL generator
expression.
Change-Id: Ia065bc1de939cee49e5de0b2aef70e356cc5419a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
This is done by adding a DEFAULT_IF argument to add_qt_plugin, which accepts
if-evaluated expressions.
e.g.
add_qt_plugin(myplugin
DEFAULT_IF ${foo} STREQUAL ${bar}
...
)
so that this mechanism can be reused later if necessary.
Change-Id: I7eba9adaaa28e55a4f0f94cf206e868b990027e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
