Backstory.
The main reason why we keep getting "unable to promote 3rd party 'X'
target to global scope" errors when building Qt repositories, is
because we try to promote 3rd party imported targets in a different
scope than where the imported targets were created.
What were the main motivations for promoting 3rd party targets to
global?
1) imported targets are by default local to the directory scope they
were created in
2) we want 3rd party targets to be accessible across subdirectory
scopes, but looked up once, e.g. qt_find_package(JPEG) looked up in
src/gui/CMakeLists.txt, but the target should also be usable in the
sibling scope
src/plugins/imageformats/CMakeLists.txt
Having the package lookup close to the consuming qt module is easier
to maintain, because all the other 3rd party dependency lookups are
in the same file. This goes against the conventional CMake advice
where each subdirectory should look for its own dependencies, or the
dependency should be available directly in the root project scope.
3) to make the 3rd party targets available in the root project scope
as part of the following flow:
QtPostProcess.cmake ->
qt_internal_create_module_depends_file() ->
qt_collect_third_party_deps() ->
get_property(INTERFACE_QT_PACKAGE_NAME) ->
write 3rd party Dependencies.cmake file for each qt module.
Properties can only be queried from an imported target if it's in
the same scope or was promoted to global, otherwise you get
'non-existent target' errors.
4) for prl and pri file generation, where we need the targets to be
available during generator expression evaluation within the
relevant qt module directory scope
Here is a list of approaches I came up with on how to improve the
situation.
1) Make all imported targets global during the Qt build, by iterating
over the directory property IMPORTED_TARGETS and making each one
global.
Requires CMake 3.21.
Status: Already implemented for a long time, but is opt-in.
Pros: Relatively robust
Cons: Minimum CMake version for building Qt is 3.16.
2) Make all imported targets global during the Qt build using the
CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable.
Requires CMake 3.24.
Status: Not implemented, but can be set by Qt builders directly on
the command line.
Pros: Should be robust
Cons: Minimum CMake version for building Qt is 3.16.
3) Abandon the desire to have a single qt_find_package in a single
directory scope, and embrace the CMake-way of repeating the
dependency in each subdirectory that requires it.
Status: Not implemented.
Pros: Should be robust
Cons: A lot of qt_find_package duplication, will require rewriting
various code paths, QtPostProcess would have to be done at
directory scope, unclear if dependency tracking will still work
work reliably when there might be multiple same-named
directory-scoped targets, other unknown unknowns
4) Move all qt_find_package calls into a $repo_name/dependencies.cmake
file which would be read at project root scope. This would
potentially avoid all scoping issues, because all dependencies will
have to be specified at root scope.
Status: Not implemented.
Pros: No duplication
Cons: Dependencies are not scoped anymore to module directories,
won't be able to conditionally look for dependencies based on
module feature evaluation, not clear yet how this will tie into
standalone tests which are in tests/ subdir, other unknown unknowns
5) Try to promote as many 3rd party libraries at project root scope
as possible.
Currently we have 2 general locations where we look up
dependencies.
One is each qt_find_package call. The other is
Qt6FooDependencies.cmake ->
_qt_internal_find_third_party_dependencies().
Many 3rd party targets are created by
_qt_internal_find_third_party_dependencies() in the root scope, but
not promoted, and then we try to promote them in child scopes using
qt_find_package, which causes the promotion errors.
Starting with 58eefbd0b6169d0749b312268c1ae1e594e04362 and
37a5e001277db9e1392a242171ab2b88cb6c3049 we now record the provided
targets of previous qt_find_package calls.
So instead of waiting to try and promote targets later during the
configuration process, we can make sure we promote the targets at
_qt_internal_find_third_party_dependencies() call time, right
when we lookup the Qt dependencies of the qt repo, in the root
scope.
Status: Implemented in this change
Notably, we only promote 3rd party targets to global for qt builds,
and not user projects, to not accidentally break user project
behaviors.
Also, we only promote 3rd party targets, and not Qt internal
targets like Qt6::Core, Qt6::Platform, Qt6::PlatformCommonInternal,
Qt6::GlobalConfig, etc, for a few reasons:
- the code that requires targets to be global only cares about
3rd party targets
- promoting the internal targets is more prone to breaking, because
there is more than one place where find_package(Qt6Foo) might be
called, and if that ends up being in a different directory scope,
we encounter the same global promotion errors.
Some notable cases where this happens:
- tests/CMakeLists.txt brings in extra Qt packages via
StandaloneTestsConfig.cmake files
- qtbase standalone tests qt_internal_qtbase_pre_project_setup()
calls find_package(Qt6 COMPONENTS BuildInternals) which ends
up creating the Platform target in the root scope instead of
the tests/ scope
- Qt6::BundledLibpng links against Core, which ends up trying to
promote Core's internal dependencies Platform and GlobalConfig
To only promote 3rd party targets, we walk the dependencies of
an initial target recursively, and skip promoting targets that have
the _qt_is_internal_target or
_qt_should_skip_global_promotion_always properties set.
Pros: Improves the situation compared to the status quo
Cons: Still not ideal due to the various filtering of internal
targets and having to mark them as such.
6) Avoid promoting targets to global if we can detect that the target
was created in a different scope than where we are trying to
promote it.
We can do that by comparing the target's BINARY_DIR to the
CMAKE_CURRENT_BINARY_DIR and skip promotion if they are not equal.
Status: Not implemented, but we can consider it because it's
quick to do.
Pros: More robust than newly implemented approach (5)
Cons: Requires CMake 3.18, because trying to read the BINARY_DIR
property on an INTERFACE_LIBRARY would error out.
Also, if we implement it and make it the default when using 3.18+,
we might 'collect' a lot more hidden promotion errors that will
only be revealed later once someone uses CMake 3.16 or 3.17,
because most will probably use newer CMake versions.
Perhaps the trade-off is worth it?
Pick-to: 6.8
Fixes: QTBUG-89204
Fixes: QTBUG-94356
Fixes: QTBUG-95052
Fixes: QTBUG-98807
Fixes: QTBUG-125371
Change-Id: I088a17a98ef35aa69537a3ad208c61de40def581
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
They will used from another Public.cmake file in a follow up commit.
Pick-to: 6.8
Change-Id: I71b69ed76ca48c391ba45329eb9c305e4a2a238b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building user projects replace the FATAL_ERROR about the missing
Qt targets with the WARNING and mention that the linking might be
incomplete. The updated check affected some user projects that used
the linking to the versioned targets and our deferred finalizers. If
Qt targets are not propagated to the global scope or not found in the
top-level directories, finalizers might fail to resolve these targets.
Now users will see the warning. The side effect of the missing targets -
missing plugin linking, or incomplete deployment, both use walk libs
results.
Pick-to: 6.5 6.7 6.8
Change-Id: I5c68b548122775424909c62f904f887417816fbc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change the way we collect dependencies in __qt_internal_walk_libs.
Prefer the versioned Qt targets over the namespaceless. This fixes the
generating of the pkg-config configs.
Pick-to: 6.5 6.6 6.7
Task-number: QTBUG-124135
Change-Id: I660376e122a99b5bc0874f2bc6ccd4d80c9ad453
Reviewed-by: Ionen Wolkens <ionen@gentoo.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since Qt targets now are linked as versioned targets by default, we
should adjust the respective check in __qt_internal_walk_libs.
Pick-to: 6.7
Change-Id: Idb896c1d9eda944a06d57b0491686cd78e010df0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Access the target name value, but not use the variable name in
when checking the target existence.
Pick-to: 6.2 6.5 6.6 6.7
Change-Id: I0f86e3c7665d9c028bf4cbdc5aa8fb840fe1d542
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When collecting the dependencies of a target, it can happen that we
encounter a target that is not visible in the current directory scope.
This can usually be fixed by moving the corresponding find_package call
to a higher directory.
Detect this situation and print a warning with instruction how to
silence this warning: either by fixing the situation or by setting
QT_SILENCE_MISSING_DEPENDENCY_TARGET_WARNING.
Fixes: QTBUG-108286
Change-Id: I9033fedbd81ef0710b7cc11fab0e94e67c74ff86
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
After the update to the CMake based build system the ability to
generate pkgconfig files, like it was with QMake, was lost.
This patch adds pkgconfig generation again via a new internal command
named qt_internal_export_pkg_config_file.
The functionality of this command consists in checking if the target
is internal. Then gets the compile definitions. It performs a search
for dependencies that is somewhat similar to
qt_get_direct_module_dependencies, although it won't recurse down for
more deps. Each dependency is then again, checked if it's internal or
has a public interface. Later these deps get deduplicated and lastly
a pkgconfig file is filled.
The resulting pkgconfig files of many of the Qt6 packages were
validated via invocations of `pkg-config --validate` and
`pkg-config --simulate` commands and later used to build local
projects plus tests that use the pkg-config provided details at
compilation time.
Although it has some limitations, with qt_internal_add_qml_module if
it specifies non-public deps these won't be listed and with non-Qt
requirements, notably in static builds, not being appended to the
PkgConfig file.
Task-number: QTBUG-86080
Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.
If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.
The project will get compilation errors if it uses Vulkan headers, but
that's intended.
This use case was broken when fixing Vulkan to be found when building
Qt for Android.
Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
consumers only if the target exists. It won't exist if Vulkan
include dirs are not found
This also requires some changes in pri and prl file generation.
For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.
For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.
We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.
As a drive-by, fix nolink handling for WrapOpenSSLHeaders.
Amends bb25536a3db657b41ae31e1690d230ef8722b57d
Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78
Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
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>
User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to
true so that the various imported targets created by find_package(Qt6)
are promoted to global targets.
This would allow a project to find Qt packages in a subdirectory scope
while using those Qt targets from a different scope.
E.g. it fixes errors like
CMake Error at CMakeLists.txt:5 (target_link_libraries):
Error evaluating generator expression:
$<TARGET_OBJECTS:Qt6::Widgets_resources_1>
Objects of target "Qt6::Widgets_resources_1" referenced but no such
target exists.
when trying to use a static Qt from a sibling scope.
Various 3rd party dependency targets (like Atomic or ZLIB) are not
made global due to limitations in CMake, but as long as those targets
are not mentioned directly, it shouldn't cause issues.
The targets are made global in the generated
QtFooAdditionalTargetInfo.cmake file.
To ensure that resource object libraries promoted, the generation
of the file has to be done at the end of the defining scope
where qt_internal_export_additional_targets_file is called,
which is achieved with a deferred finalizer.
Replaced all occurrences of target promotion with a helper function
which allows tracing of all promoted targets by specifying
--log-level=debug to CMake.
Pick-to: 6.2
Fixes: QTBUG-92878
Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Allow collecting all public dependency CMake targets starting from
a given initial target.
The new mode walks INTERFACE_LINK_LIBRARIES of a shared library
or executable target, as well as the INTERFACE_LINK_LIBRARIES and
LINK_LIBRARIES of a static library target.
Each encountered target (checked with if(TARGET)) is added the output
list.
Note that the private dependencies of a non-static target (like a
shared library or executable) are not walked by the new mode.
Introduce a new function called
__qt_internal_collect_all_target_dependencies which uses the new
mode to collect the full private dependency list of a target.
The final list only contains targets, so no linker flags or file
paths.
This list is useful to do further processing on the targets like
extracting properties from them and running finalizers.
Task-number: QTBUG-92933
Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
