target_link_options are placed by CMake at the beginning of a linker
line. This gives us an opportunity to use the function to propagate
object libraries. This change adds one more check in the root
Config.cmake file. If CMP0099 policy is enabled, CMake enables
propagating of the linking options when linking two static libraries
using the PRIVATE linking visibility, so we can rely on the correct
linking order and expect object libraries to be propagated.
Note that on the platforms where cmake version is higher than 3.16
Qt uses CMP0099 NEW in functions like qt_add_executable. This means
that at the moment of creating an executable target the TARGET_POLICY
genex will also be NEW, so we do not take into the account the user
defined CMP0099.
If the CMP0099 policy is not available for a certain CMake version
we skip the TARGET_POLICY check and simply disable propagation of
the object libraries using target_link_options for both user and Qt
libraries. This is applicable for the CMake versions 3.16 and less.
Linking approaches have the following priorities(from higher to lower)
after this change:
- target_link_libraries - works if link order matters not or CMake
version greater equal 3.21.
- target_link_options - works if CMP0099 is set to NEW by user or
if the CMake version is greater than or equal to 3.17 and an
executable is created using Qt functions.
- object library finalizer - works if CMake version is greater equal
3.19 or qt6_finalize_target is called explicitly.
- target_sources - is used when all the other approaches could not
be used.
Amends a1fd4f51ad
Amends 3329212815
Pick-to: 6.2
Change-Id: I14f88caeb04e357191c840abeab89b03e210b796
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Ensure that Qt user projects build with sanitizer flags if Qt was
configured with any of the sanitizers enabled.
To compile Qt with sanitizer support enable any of Qt sanitizer
features.
Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported
anymore.
When configuring Qt using CMake directly, pass
-DFEATURE_sanitizer_address=ON
-DFEATURE_sanitizer_undefined=ON
instead of
-DECM_ENABLE_SANITIZERS=address;undefined
When configuring Qt with the configure script pass
-sanitize address -sanitize undefined
as usual.
QtConfig.cmake now records the sanitizer options that should be
enabled for all consuming projects based on the enabled Qt features.
This applies to internal Qt builds as well as well as tests an
examples.
The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS
variable in the directory scope where find_package(Qt6) is called.
The ECMEnableSanitizers module is included to add the necessary flags to
all targets in that directory scope or its children.
This behavior can be opted out by setting the
QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might
be handling sanitizer options differently.
Amends 7e03bc39b8
Pick-to: 6.2
Fixes: QTBUG-87989
Task-number: QTBUG-92083
Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Dependency lookup mechanism is the same for modules and plugins. It
makes sense to wrap it using macro.
Pick-to: 6.2
Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove target specific flags from static_link_order.
Move the check to the common config.tests folder.
Amends 5fb99e3860
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For user projects we run the static link order check once
'find_package(Qt6 ...)' is called.
If linker can resolve circular dependencies between static libraries
and object files we set the _qt_link_order_matters property of the
Qt::Platform target. This indicates the use of finalizers is not
required and we may rely on CMake-base propagation of resource
libraries and resource object files.
If linker could not resolve circular dependencies depending on
the _qt_resource_objects_finalizer_mode value:
- Finalizer will be called and collected resource objects will be
linked to the target directly.
- Finalizer will be omitted and resource objects will be linked
using the target_sources function implicitly. This only
propagates resource one level up if consumer links the static
library PUBLICly, but all symbols will be resolved correctly
since object files are placed in the beginning of the linker line.
In the CMake version 3.21 we expect that CMake will take care about
the order of the resource object files in a linker line, it's
expected that all object files are located at the beginning of the
linker line.
TODO: Need to confirm that the CMake 3.21 meets the expectations.
Amends 4e901a2f99
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake 3.21 introduced a new IMPORTED_TARGETS directory property which
we can use to promote all imported targets within a scope to be
global.
This would cover transitive non-Qt imported targets which the Qt build
system does not know about and is thus a more complete solution
compared to promoting only Qt targets.
Run a finalizer at the end of the directory scope where
find_package(Qt6) is called to promote all imported targets within
that scope to global (when requested).
The old promotion method is disabled when the CMake version is new
enough.
Pick-to: 6.2
Task-number: QTBUG-92878
Task-number: QTBUG-94528
Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This makes qt_internal_disable_find_package_global_promotion available,
which is needed when linking against QtMultimedia in a static build
Pick-to: 6.2
Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This proposal collects all the resource objects to the qt-specific
property of the static libraries. This is done to avoid littering
of other static libraries and put resource object files to the
source part of the linker line when linking the end-point
executable.
The way we link object resource libraries is changed back to the
target_link_libraries approach as we may omit using finalizers
with linkers other than ld. Users may enforce finalizers by calling
the qt6_enable_resource_objects_finalizer_mode function if need.
Refactor tests related to the static resources.
Amends ddaa7150d8
Task-number: QTBUG-93002
Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
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>
Add an iOS specific plist file like we do for macOS.
If the user hasn't specified a bundle identifier or a development
team id, do what qmake does and query the Xcode preferences file to
pre-populate those if possible.
This allows running
cmake -GXcode ./foo
on a Qt example project and building it with xcodebuild on the
command line without having to go through the IDE to set a development
team id or modifying the example project to add a product
bundle identifier.
Note that the change assumes that the development team id has been
previously set / configured via Xcode. If no such id is found, then
the value will not be set and the user will still have to specify it
either in the project file or via the Xcode UI after the project
has been generated.
Amends 3a2fa3fec5
Pick-to: 6.1
Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Allow to set QT_ADDITIONAL_PACKAGES_PREFIX_PATH as both an env
variable and CMake cache variable. Also normalize path and list
separators, so that they can be used similar to CMAKE_PREFIX_PATH.
The environment variable is intended to be set by the conan virtualenv
generator, so that e.g.
find_package(Qt6 COMPONENTS NetworkAuth REQUIRED)
also works if NetworkAuth is not installed into the Qt prefix.
Pick-to: 6.1
Fixes: QTBUG-91142
Change-Id: Ia9f9b9fa2b1b051d33073629139640d0f4c7a843
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
'QT_HOST_PATH' indicates that we use crosscompilation toolchain
to build project. In this case 'Qt6Config.cmake' loads
'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines
correct paths to host tools.
Replace hardcoded paths for host tools by paths recorded
in Qt6HostInfoConfig.cmake.
Correct conditions for QT_HOST_PATH, evaluate it explicitly as
string, but not as boolean expression.
Fixes: QTBUG-86557
Pick-to: 6.0
Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
This reverts commit 9968a211f9.
The PKG_CONFIG_* environment variables should be added by the user
environment, preferably by the toolchain file.
Apparently, the change was added for Android before we turned off
pkg-config for Android. It is not needed anymore.
Change-Id: Ieeed09ae53a606c85d4937f463286b5b0f76bde9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
At the moment our examples require a minimum of 3.14 due to changes
in upstream CMake's Autogen functionatlity to support Qt 6. Anything
lower would simply not work with Qt 6.
It's not clear yet if we actually want to require 3.14, or something
higher. At the very least there were many significant changes to
support iOS in CMake 3.15.
But for now just bump the version checked by Qt6Config.cmake to be
consistent with what's in our examples.
Task-number: QTBUG-88086
Change-Id: I119c2ad05a18c357fe7c659b30685af87475fc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
By default, when using the Qt6 CMake package to look for components,
the find_package() calls for the components use NO_DEFAULT_PATH to
ensure that CMake doesn't accidentally find system (distro) packages.
Instead we limit the paths to one level up from where the Qt6 package
is.
Unfortunately that doesn't quite work for finding Qt packages that
might have been installed into a different prefix than where the main
Qt prefix is.
This happens when Qt addons are built by Conan, and installed into
a separate prefix.
To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work
in a scenario as described above, introduce a new variable called
QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify
additional paths where Qt CMake packages should be found.
This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH
variable which was meant for a similar case, but only for examples.
Additionally, allow disabling the NO_DEFAULT_PATH option by setting
the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE.
This would allow regular usage of CMAKE_PREFIX_PATH to work, at the
risk that system Qt CMake packages might be found.
Augments 5cd4001bf2
and ffe0889413.
Fixes: QTBUG-86882
Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
...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 reverts commit 58c1c6ee5c.
This lead to configuration errors on some machines, blocking
development.
Change-Id: I744f6cc95fbaa273519ab8fc8fb492b87f5729b8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The find_dependency() macro calls return() on failure, meaning any code
after it will be ignored, thus checking any XXX_FOUND variables after
find_dependency() is pointless.
Fix the places where we use find_dependency() and set the "failed" state
before the call and the "success" state afterwards.
Change-Id: Ia5239c704f02a9bec972210374ffed7808b14055
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We can't rely on the MACOS define as that's set by our private
QtPlatformSupport.cmake that's not shipped.
Change-Id: I86c578a282a0833408a06d923954510a3579bdaa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When cross-compiling with CMake, before this patch pkgconfig calls would
find libraries which are part of the host system and not the target
system.
The current approach used is based of the discussion present in
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4478, and should
be considered a temporary solution until the issue is properly addressed
in upstream CMake.
Change-Id: I535d4d48c2a5d34689082b80501b3b6ae30d7845
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default Info.plist shipped with CMake lacks an NSPrincipalClass
entry, which is crucial for making macOS apps run in full resolution
on retina screens.
We make sure the file is only picked up on macOS, not iOS and friends,
since those platforms require another principal class. If needed we can
extract the value out as a CMake variable and use the same file for all
Apple platforms. Doing so would assume all keys are single-platform
only, so if that's not the case we need platform-specific files.
We should probably extract the package type out as a variable too,
so that the file can be used for both apps, plugins, and frameworks,
but doing so requires setting up that variable somewhere based on
the target type, which CMake doesn't allow in an easy way.
The file itself is based on the file CMake ships, combined with
keys inherited from Qt's existing plist templates for qmake, and
adjusted to match what Xcode generates by default these days.
Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
During a static build we need to use the find modules
in 3rdparty/extra-cmake-modules/find-modules when generating a
ModuleDependencies file, so that the generated find_dependency()
calls succeed. This means that the files have to be shipped with
Qt6 package, making them pseudo public API.
There is also a need to use these files when building QtWayland.
Instead of setting / unsetting CMAKE_MODULE_PATH only in module
and plugin Dependencies cmake files, just set them once when finding
Qt6.
This will allow QtWayland and QtX11Extras to easily find the required
third party packages, without having to hardcode the paths in multiple
repos.
Change-Id: I750d0421a269e5632afa1bb62498c2501d73cdb1
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
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>
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>
This var needs the cmake namespace as prefix.
Follow-up commit of c5e2838b64
Change-Id: I595306301313b1ff911134776480d28b3194bcf8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Currently to build qtsvg we have some copy-pasted code to set up
the paths for QtSetup and QtPostProcess to be found.
To make it cleaner, introduce two new macros called
qt_build_repo_begin and qt_build_repo_end(). The first one
should be called in a child repo like qtsvg, right after
a find_package(Qt5) call, and the second one at the end of the
repo top-level CMakeLists.txt file.
In order for the macros to work, extract some of the variables
which were set in Qt5Config into Qt5CoreConfig instead. This
makes sure that it works also for find_package(Qt5Core) calls.
Task-number: QTBUG-75580
Change-Id: I85267c6bd86f9291ec2e170fddab1006ab684b5c
Reviewed-by: Simon Hausmann <simon.hausmann@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>
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@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>
