If one of the dependencies in QtFooModuleDependencies.cmake is not
found, QtFoo_FOUND will be set to False by find_dependency.
In that case, we should not create imported targets that belong to
that package.
It would be misleading for projects that do target existence checks
instead of package_FOUND checks as well as generally being
incorrect. The created imported targets might be referencing other
targets that would not exist.
Pick-to: 6.2
Fixes: QTBUG-97896
Change-Id: I09198aa3f19be047b27c29329b6e62c30fa09dc0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Craig Scott <craig.scott@qt.io>
This reverts commit 657525965b.
The change relied on reading the last value of the
CMAKE_MINIMUM_REQUIRED_VERSION variable before one of the Qt packages
is found to use it for the version check.
Even if a user project has a cmake_minimum_required() right at
the beginning of the project with a supported version specified,
the first project() call which loads a CMake toolchain file could
contain another cmake_minimum_required() call with a lower
(unsupported) version and that version would be used for the check,
failing the project configuration.
The Android NDK ships such a toolchain file, which requires version
'3.6'.
Thus, relying on the last value of CMAKE_MINIMUM_REQUIRED_VERSION is
not robust enough.
Pick-to: 6.2
Task-number: QTBUG-95018
Task-number: QTBUG-95832
Change-Id: Iff3cb0a46e6e878569dce9c5fe915a714a034904
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Qt6Config.cmake calls cmake_minimum_required to ensure a recent enough
CMake version is used in projects.
That call does not set policies in the calling subdirectory scope,
because find_package introduces a new policy scope.
If a project using Qt has a 'cmake_minimum_required(VERSION 3.1)'
call and is configured with a recent CMake, many policies will
still be set to OLD.
One such policy is CMP0071 (Run AUTOMOC on GENERATED files). The
policy value is queried at generation time rather than at target
definition time, which means we can't influence the policy value
(e.g. inside the implementation of qt_add_executable for example)
The inability to influence the policy value for targets created by our
own CMake functions is unfortunate and can lead to issues (in the case
of the above policy to compilation / linker issues).
Record the version of the last cmake_minimum_required call before
the Qt packages are found and error out if the version is lower than
the minimum supported one.
A project can reduce the error into a warning by specifying a
-DQT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT_IN_CMAKE_MIN_REQUIRED=3.xyz
option when configuring the project.
If the option is used and build issues arise, no official support is
given.
All the CMake example projects shipped with Qt specify a minimum
version of 3.16 already (which is the minimum for shared Qt builds),
so it shouldn't be an issue to require that in other user projects as
well.
Implementation wise, we follow the existing pattern to record
what the minimum and computed versions for static and shared Qt
builds are at qtbase configure time.
These are then checked before the Qt6 or QtFoo packages are
find_package'd.
Amends 6518bcc167
Pick-to: 6.2
Task-number: QTBUG-95018
Task-number: QTBUG-95832
Change-Id: I1a1d06d82f566c92192a699045127943604c8353
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Provide better error messages when a Qt package / component is not
found.
Mention the location of the expected Config file on the file system,
whether it exists
Also mention the location of the Config file that was specified by the
user when configuring the project or which CMake computed and stored
in QtModule_DIR cache var.
Mention that a package is not found in case if the main target exposed
by that package is not found.
If the target is not found, mention that it might be due to
QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true).
If it is set to true, the assumption is that the target must have been
defined by something else before the find_package call (either an
earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or
maybe it's the use case of Qt being built together with its examples
or it's a super build).
Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error
message is not spilled into any subsequent find_package(Qt6) calls,
causing a cascade of unwarranted warnings / errors.
Make sure to unset it only if components were specified, so the
message is not shown or unset in any of the recursive
find_package(Qt6) calls which is a dependency for regular Qt module
packages.
This works fine, because find_package(Qt6) calls with components are
only done in project code and not done by the transitive dependency
code (which looks for Qt6Foo packages directly).
Remove some dead code.
Pick-to: 6.2
Task-number: QTBUG-95532
Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58
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>
Unset all QT_FEATURE_foo values for every build.
If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt
build as dirty. Reset FEATURE_foo for dirty builds to the calculated
value if it doesn't meet its condition.
Set Qt module as NOT FOUND if its target was not created during
configuration.
Main issue with this approach are generated files, that became trash
once the related features are disabled. This especially affects features
that enable/disable Qt modules. FooConfig.cmake files are created and
generate lots of warnings if feature was disabled. We may introduce a
module cleanup procedure at some point.
Fixes: QTBUG-85962
Pick-to: 6.0
Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
...and fix the build errors the original change caused.
This reverts commit 127fb8bb55.
Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change provides the following per-module variables
Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS,
Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS.
These are deprecated and are only intended for easier porting from
Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets
e.g target_link_libraries(app PRIVATE Qt6::Widgets)
Note that the variable contents includes transitive values for
everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS
will contain values for Widgets, Gui and Core.
Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when
that is used in target_link_libraries(), CMake will take care of the
transitivity.
Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Every metatypes.json files is now added as an INTERFACE source file to a
target. This enables us later to correctly collect all the
metatypes.json files from dependent targets. This information is also
correctly exported via export()/install().
To avoid the metatypes.json appearing in every target's source list,
the file path is wrapped in a generator expression which will only be
evaluated when the consuming target has the property
QT_CONSUMES_METATYPES set to true. At the moment this is limited to
targets which need to interact with qmltyperegistrar.
Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch enables each module to load their own
Qt${version}ModuleBuildInternals.cmake to expose module specific
features when building Qt.
These scripts are only loaded when the package QtBuildInternals has been
loaded.
Change-Id: Ie58dd93ddd292cf106fe7ef147151a51fd5aa2b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to generator expression it is impossible to recursively evaluate the
link dependencies of a target. This is required by QtDeclarative's
qmltyperegistrar.
To overcome this we generate a ${target}_metatypes_dep.txt file which
contain lines with the following pattern:
${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt}
This can be used to recursively evaluate the dependencies at run time.
Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
We can't use qt_internal_export_modern_cmake_config_targets_file for
executables like tools, because it's not possible to use
INTERFACE_LINK_LIBRARIES with executables like you can with libraries.
We also can't create aliases to non-global imported targets.
Instead create new imported executable targets, fish out the imported
location, and assign it to the versionless targets.
Task-number: QTBUG-74137
Task-number: QTBUG-80477
Task-number: QTBUG-75984
Change-Id: I6a3c9c67ef4699c72a6c9a627c63158dfd6557f8
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The reason is that interface libraries have to have properties
prefixed with INTERFACE_ and more importantly we don't set the
property for interface libraries at the moment.
Amends d1542e8a73.
Change-Id: I86bf99995278b9086fa0e3815e10d5d54d9ea4dc
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
To build examples as part of a non-installed Qt prefix build,
not-yet-installed Config files need to be found by find_package()
calls inside example projects.
Facilitate that by propagating the CMAKE_PREFIX_PATH and
QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package()
calls where NO_DEFAULT_PATH is used.
Also adjust the inclusion of the QtFeature.cmake file to be relative
to the qt6 directory, rather than the current list directory.
This is needed to successfully find the file when parsing a Config
file from a non-installed build directory.
Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When building qtdeclarative against a static iOS qtbase build,
QtNetwork is find_package'd twice, once in the top level
CMakeLists.txt file, and once by the qtuiotouchplugin which has
Network as a dependency.
This meant that the static plugins that Network exposes had
auto import cpp files generated twice, which failed the configuration
of qtdeclarative.
To fix this, don't generate the same file more than once.
To do that, protect the inclusion of the FooPlugins.cmake file, to
only be included once in every directory scope. That can be achieved
by setting a variable to TRUE when the target does not exist yet.
If the target exists in the same scope, that means that find_package()
was called a second time in the same scope, so there is no need
to include the Plugins file.
Change-Id: I9d7c3e7b7c22c2b4526cf1d717b9d15919f213f3
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Provide add_qt_gui_executable() as function in our public API that takes
care of automaticWinMain linkage. We can use this in the future to
encapsulate similarplatform-specific behavior and adjustments, such as
module generation onAndroid.
In order for the examples to see the function in Qt5CoreMacros, three more
additional fixes were required:
* Do the build_repo_end() call _before_ attempting to build the
examples, as we need the build_repo_end() to include QtPostProcess
and complete the creation of all the target config files.
Otherwise the find_package() calls in the examples see something
incomplete.
* Add more QT_NO_CREATE_TARGET guards
* Always call find_dependency on the dependencies, regardless of the
target creation mode. This way a find_package(Qt5 COMPONENTS
Widgets) will still load Qt5CoreMacros.
Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
extend_target.
In extend_target(Foo) we go over all the ModulePrivate dependencies
to assign them to FooPrivate. To do that we use the QT_KNOWN_MODULES
variable.
The problem is that the variable gets reset when we build a new
repository, so when we build qtdeclarative, QT_KNOWN_MODULES has no
entries for Core, Gui, etc, but only Qml, Quick, etc.
And yet QmlPrivate has to depend on CorePrivate.
Change the module Config.cmake files to append their target name
to a global variable called QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE.
The global variable gets populated every time find_package(QtFoo)
is called.
Use the union of QT_KNOWN_MODULES and
QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE when considering FooPrivate
libraries.
Change-Id: Ibd9449744478cea58eb5d9737cc8887b4df92420
Reviewed-by: Tobias Hunger <tobias.hunger@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>
QT_CMAKE_EXPORT_NAMESPACE is used by the Qt packages to make features
available to the consuming CMake project. The value was moved to the
BuildInternals Config file, but that's wrong because consuming
applications not including the BuildInternals component would fail
to use any other Qt package.
Move QT_CMAKE_EXPORT_NAMESPACE to be propagated with QtCore package
again.
Amends 9542e78525.
Change-Id: I9841ac8c2828b00c0111d59e8976c889554e0ce1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
To implement this, create a new Qt5BuildInternals package.
All child Qt modules like qtsvg should use
find_package(Qt5BuildInternals) or
find_package(Qt5 COMPONENTS BuildInternals) in the their
top level CMakeLists.txt.
This will make the qt_build_repo() macros available.
For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH
pointing to the source folder that contains the BuildInternals
package.
For the other modules we actually use a configured and installed
package Config file.
This change moves variables that used to be written into the
QtCore Config file into the BuildInternals package. This way
things that are relevant only for building additional Qt modules
does not pollute the QtCore package.
Task-number: QTBUG-75580
Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Generate CMake config files which export Qt targets with a Qt:: prefix
(i.e. without a major version suffix in the namespace)
Change-Id: Ia07f98be6d0e24c196e3880b7469f1f0c6232c06
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is needed because dependencies added after add_qt_module with extend_target
are currently not taken into account.
Task-number: QTBUG-75538
Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change introduces a new function called qt_find_package()
which can take an extra option called PROVIDED_TARGETS, which
associates targets with the package that defines those targets.
This is done by setting the INTERFACE_QT_PACKAGE_NAME and
INTERFACE_QT_PACKAGE_VERSION properties on the imported targets.
This information allows us to generate appropriate find_dependency()
calls in a module's Config file for third party libraries.
For example when an application links against QtCore, it should also
link against zlib and atomic libraries. In order to do that, the
library locations first have to be found by CMake. This is achieved by
embedding find_dependency(ZLIB) and find_dependency(Atomic) in
Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake.
The latter is picked up when an application project contains
find_package(Qt5Core), and thus all linking dependencies are resolved.
The information 'which package provides which targets' is contained
in the python json2cmake conversion script. The generated output of
the script contains qt_find_package() calls that represent that
information.
The Qt5CoreDependencies.cmake file and which which dependencies it
contains is generated at the QtPostProcess stop.
Note that for non-static Qt builds, we only need to propagate public
3rd party libraries. For static builds, we need all third party
libraries.
In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any
scope, the targets on which the property is set, have to be GLOBAL.
Also for applications and other modules to find all required third
party libraries, we have to install all our custom Find modules, and
make sure they define INTERFACE IMPORTED libraries, and not just
IMPORTED libraries.
Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Enables the use of e.g. QT_NO_DEBUG in compiler flags, -fPIC, passing on of
QT_NAMESPACE, etc. pp.
Dropping a lot of custom code which handled adding imported targets for
the command-line tools (this is all being handled by CMake already).
It needs to be investigated if we need to resurrect
Qt5GuiConfigExtras.cmake.in in one way or the other.
Change-Id: I4fa141b68fddaad4f33e628c59d5d0b3a7b3a096
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
For now create targets a la "Qt5::Core" to stay compatible with the
current Qt5 naming scheme. The name is controllable via a CMake option.
Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the
prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake")
Also make sure to `find_dependency(...)` the required packages inside
the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake,
search for Qt5Core, etc. pp..
Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6
Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This is less self-contained than what we have, but significantly speeds
up cmake configure/generate runs.
This patch also warns when a feature is already defined.
Change-Id: I8cab63e208ba98756b47d362a39b462f5ec55e20
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
