diff options
author | Alexandru Croitor <alexandru.croitor@qt.io> | 2021-05-11 11:19:19 +0200 |
---|---|---|
committer | Alexandru Croitor <alexandru.croitor@qt.io> | 2021-05-18 22:03:46 +0200 |
commit | 91c65dd80cdd2de666448c14202c0c63718152b6 (patch) | |
tree | 4fd82f1b93cd38a8ab915bcf051e7ef0750fad46 /src/3rdparty/dbus-ifaces/org.kde.StatusNotifierItem.xml | |
parent | 208dbb4c18105e430dfcdfd649456202c603e242 (diff) |
CMake: Build plugin initializers as object libs
Instead of compiling the plugin initializers as part of a user
project, pre-compile them as object libraries while building Qt.
The installed object libraries can then be used with
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
so that they are linked into the final executable or shared library
via qt module usage requirement propagation.
This reduces the build times of user projects.
The link line placement of the object files should be correct for all
linux-y linkers because the only dependency for the object files is
Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that
from empirical observations.
As a consequence of the recent change not to link plugin initialization
object files into static libraries, as well not having to compile the
files in user projects, we can get rid of the
_qt_internal_disable_static_default_plugins calls in various places.
A side note.
Consider a user static library (L) that links to a Qt static library
(Gui) which provides plugins (platform plugins).
If there is an executable (E) that links to (L), with no direct
dependency to any other Qt module and the intention is that the
executable will automatically get the platform plugin linked,
then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage
requirements are propagated successfully.
This is a limitation of using
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
which will propagate object files across static libraries only if
qt_module is linked publicly.
One could try to use
target_link_libraries(qt_module
INTERFACE $<TARGET_OBJECTS:plugin_init>)
which preserves the linker arguments across static libs even if
qt_module is linked privately, but unfortunately CMake will lose
dependency information on Core, which means the object files might be
placed in the wrong place on the link line.
As far as I know this is a limitation of CMake that can't be worked
around at the moment.
Note this behavior was present before this change as well.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Diffstat (limited to 'src/3rdparty/dbus-ifaces/org.kde.StatusNotifierItem.xml')
0 files changed, 0 insertions, 0 deletions