summaryrefslogtreecommitdiffstats
path: root/src/widgets/doc/snippets/code/src_gui_kernel_qapplication.cpp
diff options
context:
space:
mode:
authorAlexandru Croitor <alexandru.croitor@qt.io>2021-05-11 11:19:19 +0200
committerAlexandru Croitor <alexandru.croitor@qt.io>2021-05-18 22:03:46 +0200
commit91c65dd80cdd2de666448c14202c0c63718152b6 (patch)
tree4fd82f1b93cd38a8ab915bcf051e7ef0750fad46 /src/widgets/doc/snippets/code/src_gui_kernel_qapplication.cpp
parent208dbb4c18105e430dfcdfd649456202c603e242 (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/widgets/doc/snippets/code/src_gui_kernel_qapplication.cpp')
0 files changed, 0 insertions, 0 deletions