| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change introduced in 98e8180e56322ce065e39cc1ef1d65b54caa8c25
fixes reconfiguration issues for repositories that provide plugins
associated with modules from a different repository
(QSvgPlugin -> QtGui -> qtbase).
It does so by only loading the public Plugin CMake packages of
dependent repositories.
For executables / tests that are built as part of the current
repository, plugins are linked via a different simplified mechanism in
qt_add_internal_plugin and qt_internal_add_plugin in order to prevent
exporting link cycles between plugins and Qt modules.
This works for the majority of in-tree tests, but unfortunately breaks
static standalone tests.
For example in qtbase neither mechanism will link plugins to the
standalone tests:
- qtbase has no repo dependencies, so the first mechanism (loading of
public plugin packages) is skipped because we assume we are merely
reconfiguring the main build of qtbase and we don't want to
accidentally create duplicate plugin targets
- because a standalone test configuration does not call
qt_internal_add_plugin, no association is done between qt plugin
and module and thus all tests (qt_internal_add_test ->
qt_internal_add_executable) don't get the simplified plugin
linking
Fix this by allowing loading of the public CMake plugin packages when
doing standalone tests. It should be safe to do so because we don't
build any plugins in this case, only tests.
Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25
Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a CMake release introduces a new policy that affects most Qt
modules, it may be appropriate to make each module aware of that newer
CMake version and use the NEW policy without raising the minimum CMake
version requirement. To reduce the churn associated with making that
change across all Qt modules individually, this change allows it to be
updated in a central place (qtbase), but in a way that allows a Qt
module to override it in its own .cmake.conf file if required (e.g. to
address the issues identified by policy warnings at a later time). The
policies are modified at the start of the call to
qt_build_repo_begin().
For commands defined by the qtbase module, qtbase needs to be in
control of the policy settings at the point where those commands are
defined. The above mechanism should not affect the policy settings for
these commands, so the various *Config.cmake.in files must not specify
policy ranges in a way that a Qt module's .cmake.conf file could
influence.
Starting with CMake 3.12, policies can be specified as a version range
with the cmake_minimum_required() and cmake_policy() commands. All
policies introduced in CMake versions up to the upper limit of that
range will be set to NEW. The actual version of CMake being used only
has to be at least the lower limit of the specified version range.
This change uses cmake_minimum_required() rather than cmake_policy()
due to the latter not halting further processing upon failure.
See the following:
https://gitlab.kitware.com/cmake/cmake/-/issues/21557
Task-number: QTBUG-88700
Pick-to: 6.0
Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building a user project in Release configuration against a Qt built with
CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project
being linked against the Debug Qt libraries. This is especially painful
with MSVC where debug and release runtimes are incompatible.
We now create *AdditionalTargetInfo.cmake files along the
exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties
to the values of the release config Qt was built with.
User projects built with an unknown
configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a
release Qt. This can be controlled by setting the variable
QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user
project.
Fixes: QTBUG-86743
Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For qt_import_qml_plugins to work, it needs to have access to the Qml
plugin targets by the time find_package(Qt6Qml) is called.
To do that, we modify the generation of Qml plugin Config, Targets and
Dependencies files to go into a special 'QmlPlugins' subfolder of the
Qml package.
The Qml package will then GLOB include all the Config files in that
folder, to make them available whenever find_package(Qt6Qml) is
called.
This is similar to how the Qt plugins were glob included in the CMake
integration of Qt 5.15. In fact that glob including is missing in Qt 6
for regular Qt plugins, and should be implemented in a following
change. Currently the Qt Plugins config files that are included are
hardcoded to the list of known plugins at Qt configuration time.
As a drive-by to make this all work, the naming of the various Config
and Dependencies files has been normalized to include the Qt6 prefix.
This is done for both regular Qt plugins and Qml plugins.
Task-number: QTBUG-85961
Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
| |
Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first issue is that instead of arg_OUTPUT_TARGET we should use
rcc_OUTPUT_TARGET (there was also a typo in the OUTPUT word).
The second issue came with the fact that the object library targets
that were created for resources had a "Qt6::" namespace prefix in the
exported Targets files, and yet the link generator expression did not
contain the prefix. This failed when building qtsvg in a static build,
because the exported object library could not be found.
The solution is to use the TARGET_NAME generator expression which
takes care of adjusting the name of the target when exported, thus
making the linking work both when building qtbase and when building
qtsvg.
This had the fallout, that all resource object libraries need
to be associated with an export set and installed. This wasn't the case
for plugins, because plugins have an export name of the form
"FooTargets", whereas the export name for the resource object library
is "Qt6FooTargets".
Adjust the export names of plugins to be the same as for modules and
resource library objects (aka contain the "Qt6 prefix").
Change-Id: I1ca28d20c51e4447e5783cc20571a68ec77f6513
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
This commit introduces infrastructure work to allow static builds of Qt
to handle importing of plug-ins.
Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
