On QNX 7.1 x86drm.h is located under <...>/usr/include/libdrm, unlike
linux where it's present under /usr/include.
find_path would not find it on QNX, and instead get /usr/include from
host, which resulted in a failure to compile.
Task-number: QTBUG-83202
Change-Id: I03d6c2d4dfbe91bb70df0a322e84890bd7c8548a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qmake it's done for all qmake projects, in CMake we lean on the
safe side and apply it to building Qt itself. User CMake projects can
then choose to add it themselves.
Task-number: QTBUG-85992
Change-Id: I51919f947d43ffd9925e3d2837dcad17e480367d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There are inconsistencies in the default optimization flags added by
CMake across configurations like Release and RelWithDebInfo.
In particular Release uses -O3, whereas RelWithDebInfo uses -O2,
as well as usage of /INCREMENTAL in release configs with MSVC, etc.
To make sure that the Qt 6 binaries built with CMake are consistent
across configs, as well as consistent with the flags we used when
building Qt 5 with qmake, add a horrible search and replace mechanism
to replaces the CMake flags with what our mkspecs indicate to use.
Ideally this would be done by providing custom CMake toolchain files
for each platform we support, and we might revisit that later if the
need really arises.
To implement the replacing, we first need the flags that should be
added. Port the QMAKE_CFLAGS_OPTIMIZE variables to CMake, which is
done in QtCompilerOptimization.cmake.
Then a new function called
qt_internal_set_up_config_optimizations_like_in_qmake will look for
any kind of optimization flags set in the
CMAKE_<LANG>_FLAGS_<CONFIG> style variables, remove them, and add
the appropriate flags that qmake mkspecs provide.
On some platforms (like Windows MSVC) the function also alters the
linker CMAKE_${TYPE}_LINKER_FLAGS_<CONFIG> style variables.
The mechanism allows opting out of this replacing by
setting the QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS value.
It also allows opting into removal of flags for custom configs by
providing QT_ADDITIONAL_OPTIMIZATION_FLAG_CONFIGS. It's only removal,
because we wouldn't know what kind of config it is, and thus what
flags to add.
The currently modified configs are: Release, RelWithDebInfo,
MinSizeRel, Debug aka the usual default CMake provided ones.
The mechanism is only applied to C-like languages.
ASM is not handled to be on the safe side due to not knowing what kind
of compiler flags the platform assembler might take.
It's also important to skip RC on MSVC platforms.
Task-number: QTBUG-85992
Change-Id: I3712d5cd5a34fceab54f56a6fa46b4e678952362
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The CMake configure process fails without include guards for these
two find modules on QNX.
Task-number: QTBUG-83202
Change-Id: I3cc589f98bc3b6b22c401421927ee6dab2663fb7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QNX doesn't come with pkg-config support.
Task-number: QTBUG-83202
Change-Id: I2ac0c014a071b83ef9a2d8114bae0e9ff9b3b422
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The configure argument -qreal <type> maps to the CMake argument
-DQT_COORD_TYPE=<type>.
Fixes: QTBUG-83325
Change-Id: I94970f31ccfb241b1dd4f1d9b6cef25d6684dc05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce new CMake variables and map
-D to QT_EXTRA_DEFINES,
-I to QT_EXTRA_INCLUDEPATHS,
-L to QT_EXTRA_LIBDIRS,
and -F to QT_EXTRA_FRAMEWORKPATHS.
Those variables only affect the Qt build, not user projects.
Fixes: QTBUG-85878
Change-Id: I229df2eed1505a2619068d0d32975962b052569a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We extend configurejson2cmake to read the "commandline"
information from configure.json. This data is then translated to CMake function
calls and written it into commandline.cmake files.
We extend QtProcessConfigureArgs.cmake to pick up those commandline.cmake
files to feed our command line handling code, which is a
re-implementation of the command line handling in qt_configure.prf.
The command line handler sets INPUT_xxx variables, similar to
configure/qmake's config.input.xxx variables. The INPUT_xxx values are
translated
- to -DFEATURE_xxx=ON/OFF arguments if the input represents a feature,
- to corresponding CMake variables if such a variable is known,
- or to -DINPUT_xxx=yyy CMake arguments.
Configure arguments that have an entry in
cmake/configure-cmake-mapping.md are actually implemented. Other
arguments are likely to need more work.
Task-number: QTBUG-85373
Change-Id: Ia96baa673fc1fb88e73ba05a1afb473aa074b37d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To fix CMake Qt For Android projects to configure, we need to move
some functions from a private CMake API file only, to a public one.
Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package.
We'll have to decide how we proceed with Qt5AndroidSupport.cmake,
because that file automatically runs code when included in Qt5, and we
usually don't want to do it.
We'll also have to decide how to handle the define_property() calls
that are still left in the private QtPlatformAndroid.cmake file.
With this fix, Qt example CMake projects that use
add_qt_gui_executable should now be buildable. An APK can be created
with 'ninja apk'.
Unfortunately Qt Creator 4.13 does not currently seem to support
opening and building CMake Qt For Android projects properly.
While the build succeeds after fiddling with the Kit settings, the APK
deploy step fails to run (at least on my machine).
So the simplest way to run the built APK is to open the android-build
dir with Android Studio and launch the example application from there.
Task-number: QTBUG-85399
Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Fix detection of qt android platform plugin by globbing inside
the install qt6 prefix location. This is just a sanity check.
Fix platform plugin detection for CMake standalone tests configured
using qt-cmake-standalone-test, which used to look into the fake
standalone prefix location instead of the real Qt location.
Fix detection of stdlib path using CMAKE_SYSROOT.
Add a global apk target that allows easier building of all apk targets
defined in the project. Creation of this target can be opted out by
setting QT_NO_GLOBAL_APK_TARGET to TRUE.
Amends b1f8ca8032.
Task-number: QTBUG-85399
Change-Id: Ic9c1646b4f00e0084fe3f4397df471b8f925afd8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The helpers can now be included manually in a project to call any
required function. There was a use case for that in qttools, which was
not possible because including QtPostProcess early would produce side
effects.
Task-number: QTBUG-86035
Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
QtBuild.cmake is huge. Split it.
Move module, plugin, tools, executables and test related functions out
of QtBuild.cmake into separate files.
Do the same for many other things too.
An additional requirement is that all the new Helpers files only
define functions and macros.
No global variable definitions are allowed, nor execution of commands
with side effects.
Some notes:
qt_install_qml_files is removed because it's dead code.
Some functions still need to be figured out, because they are
interspersed and depend on various global state assignments.
Task-number: QTBUG-86035
Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The endless saga of fighting with qt_find_package and global target
promotion. In certain scenarios we want to opt out of target promotion
to global scope.
One such case is in qttools with WrapLibClang and Threads::Threads.
Threads::Threads will be found in the top-level scope via
Qt6Dependencies.
WrapLibClang is declared in src/ directory scope, and
then we try to promote it ands its dependencies to the global scope,
via qt_find_package() ->
qt_find_package_promote_targets_to_global_scope().
This fails because we can't promote Threads::Threads due to it being
added in a different subdirectory scope.
Introduce 2 new functions.
qt_internal_should_not_promote_package_target_to_global and
qt_internal_disable_find_package_global_promotion.
The first one is used to disable promotion of targets to global scope
in qt_find_package.
To mark a target not to be promoted, the second function is used.
It will be used by qttools for the WrapLibClang case.
Task-number: QTBUG-85877
Change-Id: If6caf10a94999402026517a623ae29e3ab1eeb7f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Also use the value to actually write it into qconfig.cpp so that qmake
reports the right information.
Change-Id: Icc4bf36b0dc6ad75d93ac16f39e5b361c0ce52b4
Fixes: QTBUG-81289
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Our initial approach to looking for host Qt tools when cross-compiling
to a platform with a different architecture bitness compared to the
host one was to unset CMAKE_SIZEOF_VOID_P before calling
find_package(Qt6FooTools) and then restoring the value.
That works to bypass the architecture bitness test in the
ConfigVersion files, but it also influences the paths that
find_package() searches in, specifically the lib<arch> paths like
/usr/lib64 will not be searched in.
Fortunately since CMake 3.14, write_basic_package_version_file() can
take an additional ARCH_INDEPENDENT parameter. This disables the
architecture bitness test when looking for the package, while allowing
to still search in the /usr/lib64 like paths.
Use it when creating the QtFooToolConfigVersion.cmake files.
One could argue we should actually check if the tool executables could
run on the host system where find_package is called for
cross-compilation.
We could do that in another change if the problem ever arises.
Amends 03aa74e40d
Amends 914b367c7f
Change-Id: I1181ff637ac80064a6a8538170b28a41743fc90c
Fixes: QTBUG-81672
Reviewed-by: Christophe Giboudeaux <christophe@krop.fr>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This file provides common feature-functionality is supposed to be
included by QtFeature.cmake and QtProcessConfigureArgs.cmake.
Change-Id: Ifb483c2a9c4014d240c2a4d6ff07b5c0ceee9c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the user specified CMAKE_OSX_DEPLOYMENT_TARGET=10.15 for the Qt
build then building projects with qmake failed, because the mkspec
hard-codes QMAKE_MACOSX_DEPLOYMENT_TARGET to 10.14.
We now write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.pri to override
the mkspecs' default.
Fixes: QTBUG-85923
Change-Id: I6a39cfe047ac0f99e1da0ca0728d63c741bd4fed
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This automatically sets the CMake Generator to be the same as the one
used for qtbase.
Change-Id: If9e1a6942520417393055c572f0d892efca43d2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apparently CMake encods targets from different scopes with a different
encoding scheme for earlier CMake versions.
CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50>
CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@
Handle the earlier version approach as well. It needs to be done both
when writing out 3rd party dependencies, as well as for lib prl files.
Possibly in more places as well, but I didn't detect additional
places yet.
Amends 92ee9bd6b8
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It's not immediately obvious that you need to use
all underscores for the feature name, so add a
line that explaines it.
Change-Id: I508eaf909c808fb0a93442f6e71428c18559b965
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We expose it in the private QtBuildInternals package, but we need it
also as public information for consumption in qt_import_qml_plugins()
to decide whether it should do anything.
Change-Id: If135ae596b4edaf8e2c458f6a2518b968c6d01c4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Embed package versions into the qt_find_package calls for various
Linux specific packages.
Task-number: QTBUG-82917
Change-Id: I5d1cb623f81932dfae4658b8a3a89eedb71ea3af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If certain 3rd party libraries have a version that's not suitable for
Qt, the configure summary should say so, rather than use them and fail
at build time.
With the current situation, we have to duplicate the version
information from the configure.json files in helper.py, by assigning
the version number as an extra find_package variable.
Rerunning configurejson2cmake then embeds this version info into the
qt_find_package calls in configure.cmake.
Some of the Find modules are rewritten to take the specified version
into account when looking for the libraries.
This involves moving around the code for creating a target, after
calling find_package_handle_standard_args() so we know if a good
enough version was found.
Task-number: QTBUG-82917
Change-Id: I139748d8090e0630cda413362760034dc3483e11
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Before clang 9, it was enabled by default
when -fsanitize=undefined was set.
Pick-to: 5.15
Change-Id: I0faf3ae1901d4badc6d265fa8081185be4360636
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Most of the time lld just gets stuck (deadlock) waiting on some
mutex, thus failing integrations.
Amends 64c111e10f
Task-number: QTBUG-85911
Change-Id: Id73bf967a7aeb0e0cbccfaafe056b325c8711f82
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Static Qt plugins should not be included in the list of libraries of
a prl file. They end up being there due to our circular dependency
trick where the plugins depend on the module they belong
to.
This in turn causes the giant static plugin generator expressions to
be processed in qt_collect_libs(), and the generated prl file ends up
having target names like Qt6::QJpegPlugin which are obviously not
linker flags.
To eliminate the static plugins from prl files, add an additional
dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>'
that always evaluates to true. We can string match on this expression
in qt_collect_libs, and thus remove the whole static plugin genex
entry.
This should fix linking of apps with qmake that use a CMake-built
static Qt.
Task-number: QTBUG-85865
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6
Reviewed-by: Cristian Adam <cristian.adam@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>
The include directory in Qt's build directory is always named
"include", no matter what the value of INSTALL_INCLUDEDIR is. The main
reason is that the name "include" is hard-coded in syncqt.
The INSTALL_INCLUDEDIR variable must only affect the installation
location of headers.
Fixes: QTBUG-85893
Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The logic is a bit involved in qmake.
The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies
to qt modules, qt plugins, qml plugins, qt helper libs, winmain and
qt_apps, qt_tools, but NOT tests (which is important because the tests
on Windows MinGW fail to build without the GNU extensions).
Then default_post.prf checks for the strict_c++ value and either uses
the strict or non-strict C++ standard flags. default_post.prf is
loaded for all qmake projects, not just the Qt internal ones.
Now CMake doesn't provide a transitive based option to disable C++
GNU extensions with a mechanism similar to target_compile_features.
It only provides the CXX_EXTENSIONS property and it's associated
CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a
directory scope, because that is too coarse grained.
So we rely on setting the property via a function in every relevant
qt_add_<target> function.
Now the naming of the function is weird.
We name the function as qt_internal_<...>, because it's not meant to be
used by Qt users.
We prepend an underscore to the name because we need to place it in
Qt6CoreMacros, so that the function can be called by
qt_add_qml_module which IS a public function.
That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 +
CMake we decided to make qt_add_qml_module() as public API.
Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Windows shared library prl files should not have a
QMAKE_PRL_LIBS section. Such information is not useful because it's
not used by the linker as per 523c7e3fd5
Amends 46d7abc9172f82756ccd3641a314dcc066353c3f
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This adds the option to build Qt with libb2, which is especially
recommended, if you care about the performance of the BLAKE2 hashing
algorithms. The bundled version is the pure reference C implementation
of BLAKE2, while libb2 has many additional hardware optimizations.
However, the API of both is the same, so no changes to the code were
necessary here.
Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apply the same kind of transformations to the contents of the prl
files as we do for pri files. Mainly, transform system library paths
that are absolute, into link flags to make them relocatable across
systems.
Also change the Qt frameworks to be linked via the -framework flags
instead of via absolute paths.
Implementation notes
Move the common required functions for both QtFinishPrlFile and
QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file.
Make sure it's listed as a dependency for the custom commands.
Also make sure to pass the necessary input values like possible
library prefixes and suffixes, as well as the link flag.
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This new function is meant to be used where load(qt_app) is used.
It delegates functionality to qt_add_executable, while handling
some additional behavior via a finalization function (mostly handling
of macOS Info.plist files and icons, as well as Windows icons and
resource files)
It uses a new PlatformAppInternal interface target.
Task-number: QTBUG-85757
Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Our CMake build system only generated working .prl files for
the Release configuration in debug_and_release.
This caused a linking failure when building a Widgets example that
links against qtmain, specifically
qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external
symbol __imp_CommandLineToArgvW referenced in function WinMain
The symbol is located in shell32.dll, which was not linked in, because
there was no qtmaind.prl file.
The fix to generate per config prl files is a bit complicated, because
add_custom_command does not support generator expressions in OUTPUT
and DEPENDS.
Instead we pre-generate 2 files per config, one with the preliminary
prl file content and another file that contains the final prl file
path (via generator expression).
Then we iterate over all configurations and create custom commands
with well known paths, and the final prl file is created by the script
called by the command.
Amends 06557312d2
Task-number: QTBUG-85240
Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
On Windows, if Qt is built with Vulkan support but the user's machine
does not have Vulkan, it should still be possible to configure and
build an application (if the application does not use Vulkan of
course).
When Qt is built with qmake, the special windows_vulkan_sdk.prf file
makes sure not to export build time Vulkan include headers into the
generated .pri files. The same file also tries to find the include
headers via an environment variable. If it isn't set, it just adds a
bogus "/include" include path, which doesn't fail a user's application
build.
This wasn't the case for an application built with CMake, because the
exported Vulkan_nolink target uncodinitionally referenced Vulkan's
target properties. Which means that if the Vulkan package was not
found, the application failed to configure.
To mimic qmake's behavior, make sure to query the target properties
only if the Vulkan target exists, via the TARGET_EXISTS generator
expression.
Apply the same logic to all _nolink targets. This might not be
entirely correct in all cases, but we can revise this behavior later
after more feedback. At the very least it allows building non-Vulkan
based applications.
Task-number: QTBUG-85240
Change-Id: Iffbb03a84e8637ed54d0811433e66fe6de43d71f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This fixes the macOS build when you only have the CommandLineTools installed.
Change-Id: I620bc535b508b604a875f53dec8c57af23efeac1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
While trying to implement the 'host artifact reuse' Coin instructions
change, a bug surfaced where the qemu configurations didn't find
the host tools and instead tried to use the cross-compiled tools
while building qtbase, which failed due to not finding the
runtime linker (another unsolved issue).
Before the host artifact reuse change, the host tools were found
successfully.
The difference that caused the issue is that the target install prefix
was a direct subfolder of the host prefix.
host - /home/qt/work/qt/install
target - /home/qt/work/qt/install/target
Before the host reuse change the install prefixes were as follows
host - /home/qt/work/qt/install/host
target - /home/qt/work/qt/install/target
While looking for the Qt6CoreTools package, we temporarily set
CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first
'/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'.
CMake then reroots the CMAKE_PREFIX_PATH values onto values in
CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search.
Rerooting essentially means concatenating 2 paths, unless the
considered prefix is a subfolder of the root path.
What happened was that the first considered value was
'/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent
location that gets discarded.
The second considered value was '/home/qt/work/qt/install/target.
The second value is the result of seeing that
'/home/qt/work/qt/install/target' is a subfolder of
'/home/qt/work/qt/install' and thus the root path is stripped.
All of this is done in cmFindPackageCommand::FindConfig() ->
cmFindCommon::RerootPaths.
The behavior above caused the target tools be found instead of the
host ones.
Before the host reuse change, both of the initial constructed prefixes
were discared due to them not existing, e.g.
'/home/qt/work/qt/install/target/home/qt/work/qt/install/target'
and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host'
One of the later prefixes combined CMAKE_FIND_ROOT_PATH ==
'/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting
in '/home/qt/work/qt/install/host/' and this accidentally found the
host tools package.
We actually stumbled upon this issue a while ago when implementing Qt
5.14 Android CMake support in 52c799ed44
That commit message mentions the fix is to add a "lib/cmake"
suffix to the PATHS option of find_package().
This would cause the subfolder => strip root behavior mentioned
above.
So finally the fix.
First, make sure not to append QT_HOST_PATH in the toolchain file,
there shouldn't be any need to do that, give that we temporarily set
it when looking for Tools packages.
Second, recreate the subdir scenario in the Qt toolchain file by
setting CMAKE_FIND_ROOT_PATH to the current (relocated) install
prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value
poining to the CMake directory.
Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'.
Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt
toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host
equivalents of the target ones above. Use these values when looking
for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing
the subdir behavior.
Note these are currently absolute paths and are not relocatable.
We'll have to figure out if it's even possible to make the host path
relocatable.
Finally as a cleanup, look for the Qt6HostInfo package in QtSetup
strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find
a system Qt package.
Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
gcc doesn't report warnings for final methods since version 9.2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Change-Id: I7152351aac0e3bad86d777e119f25137ef97ec6f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Change added dep in qt_add_cmake_library():
PlarformModuleInternal -> PlatformCommonInternal.
Change-Id: I303a6a520f0dda7260b12cb21673b8f1a23d536b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
