CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The find_package calls need to happen after we set INSTALL_EXAMPLEDIR
to ensure that INSTALL_EXAMPLEDIR is overridden if necessary.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-102879
Change-Id: I3c2e6c5a68a8c6ff9b98b79dbd6c83445d8da052
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also consolidate several find_package(Qt6 ...) calls in one call.
Task-number: QTBUG-98867
Change-Id: Idfd5e71f46d4489fac7411cbfadb84437a0658f3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Previously we only created object library static plugin initializers
for Qt plugins only, not user-project plugins.
The reason was that if a user tried to install the plugin target via
an export set, CMake would error out saying that the _init library is
not part of the same export set.
Introduce an OUTPUT_TARGETS option that would allow projects to get
the name of the generated _init target, so they can install it if
needed.
This was already done for qt6_add_qml_module, so we just introduce the
same option for qt6_add_plugin.
Now user static plugins will have an _init target created, which will
be propagated to consumers whenever the consumers link against the
plugin itself.
We also need an internal option to disable this propagation, because
it's handled a bit differently for Qt plugins which can be linked
either via finalizers or via usage requirements.
Amends 91c65dd80c
As a result of the implementation change, cleanup example projects
to ensure that they build successfully (the important part is
specifying the CLASS_NAME).
Only plugandpaint works properly with both shared and static Qt
builds.
echoplugin works with a shared Qt build, but not a static one due to
some assumptions in the C++ code about shared plugins.
styleplugin doesn't seem to work properly neither with shared Qt
builds nor static Qt builds, at least on macOS. But it builds fine.
For some reason even if the plugin is found, the style is not applied.
Amends 4caac1feea
Pick-to: 6.2
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This changes many different CMake places to mention Qt6 instead of
Qt5.
Note that some old qt5 cmake config files in corelib are probably not
needed anymore, but I still renamed and kept them for now.
Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
Create CMake config files which can be used from the very same CMake
project. These CMake config files simply do not create any targets,
controlled via the QT_NO_CREATE_TARGETS.
This patch also allows to build qtbase.git:examples as a standalone
project, against an already-built Qt.
Ran this:
ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example
Task-number: QTBUG-74713
Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Kai Köhne
Lucie Gérard
Alexandru Croitor
Joerg Bornemann
Kevin Funk
Tobias Hunger