Some apps may need more initial memory when linking, emscripten will
fail with:
wasm-ld: error: initial memory too small
This increases the default initial memory form 16MB to 20MB.
Larger apps might still get this error, in which case
QT_WASM_INITIAL_MEMORY can be set.
Pick-to: 6.2
Fixes: QTBUG-97457
Change-Id: Icdc56c41fb3a3852a9a83f7a3dc15820e83e1148
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Misc. fixes, including:
Fix a couple of typos in the JavaScript code. Also, macros-
within-macros don’t work, (without resorting to preprocessor
token pasting), so remove the debug output for now.
Limit the exec() “simulateInfiniteLoop” workaround to
top-level application exec() only. This way, asyncify
can be used for nested QEventLoop::exec() calls. (Emscripten
supports one level of suspend only, so we don’t want
to use that for the top-level exec(), but instead use it
for dialogs and such).
Use the new QEventLoop::ProcessEventsFlag::ApplicationExec
enum value to detect the exec() call type.
Change-Id: Ic702bfc31faf2e9f84ac5d3ccf43d067c5c61bf0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The qt_finalize_framework_headers_copy function uses the module
QT_COPIED_FRAMEWORK_HEADERS property to generate the dependency list
for the ${target}_framework_headers target. In a common case elements
can be added to the QT_COPIED_FRAMEWORK_HEADERS property after the
qt_internal_add_module command call, that's why we need to make sure
that qt_finalize_framework_headers_copy is called after collecting all
headers assigned to the module.
Pick-to: 6.2
Change-Id: I2878fa6b8d4b11677c3f48345bf6e239221074c2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To be consistent with prepare_qdoc_args.
Pick-to: 6.2
Change-Id: Ibd40d6c26f6f6fa49ea78b6476f396153b7c4ee5
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
The function qt_commandline_assignment and everything related to it is
removed from configure. It was only used in qtbase, and all usage has
been removed.
More general variable assignments will be added in a subsequent commit.
Task-number: QTBUG-88210
Change-Id: I7cfa782e89914f2b0dc0277c46e425c8a825557e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's been deprecated since Mac OS X 10.5.
qmake templates fixed in 0768a28fbf.
Task-number: QTBUG-74872
Pick-to: 6.2
Change-Id: If7d988f27f07b6fa095b2ea51a87c306361d63d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's been there for ages, we may as well use it and remove unnecessary
complexity from CMake.
Pick-to: 6.2
Change-Id: I2bbf422288924c198645fffd16a9742567a7e4af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake's Modules/Platform/Android-Initialize.cmake was setting
CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to OFF and host perl was not
picked up in PATH on Windows when building for Android.
Pick-to: 6.2
Change-Id: Ic98d8b38425231ef6aaf173fdfe958b573cc0c40
Reviewed-by: Craig Scott <craig.scott@qt.io>
One can now pass -DQT_REQUIRE_HOST_PATH_CHECK=OFF or
-DQT_REQUIRE_HOST_PATH_CHECK=ON to force disable or enable
the QT_HOST_PATH and QT_HOST_CMAKE_DIR_PATH validity checks.
One potential use case is if a project wants to manually find
QtFooTools packages by manipulating CMAKE_FIND_ROOT_PATH and such,
in which case they might not want to pass a QT_HOST_PATH.
Another potential use case is cross-building Qt with
-DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON and allowing the same
generated toolchain file to be used on the device image.
By default the generated toolchain file would require a host path
because it expects that it's still being used for cross-compiling.
But once the toolchain file is deployed to the device there's no need
to use the host tools anymore.
Another use case is building a desktop Qt using the host tools of
another desktop Qt. The new desktop Qt can use its newly built tools
just fine and wouldn't need the original desktop Qt tools.
QT_REQUIRE_HOST_PATH_CHECK needs to be added the list of vars to pass
through to try_compile calls.
Change-Id: I4b922b5d854828e6b9210dd8c07b4b1b8630aad1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Craig Scott <craig.scott@qt.io>
The environment variable check to set extra env vars
was using invalid syntax. The condition always resolved to TRUE
which means the env vars were constantly re-assigned inside each
try_compile project.
To check for undefined-ness, one can use if(NOT DEFINED ENV{...})
To check for false-ness, one can use if(NOT "$ENV{...}")
To check for string emptiness, one can use
if(NOT "$ENV{...}" STREQUAL "")
In this particular case checking for false-ness is good enough.
The extra re-assigning had no visible effect, so this is just cleanup.
As a drive-by, clarify one comment.
Amends ca59c20939
Pick-to: 6.2
Change-Id: I8fd400101efa9e610a81268c33cac8c0cb33cba3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Instead of hard-coding a lib/cmake suffix to CMAKE_PREFIX_PATH
use the parent directory of the Qt6HostInfo package which is always
searched for when QT_HOST_PATH is set.
Amends d2359b2d4e
Pick-to: 6.2
Change-Id: I7f3c8fe17bc82f733580d68d928146434a57d849
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously when one wanted to use a cross-compiled Qt with a host Qt
installed in a non-default location, they'd have to provide both
QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR.
This change will now try to first check if ${QT_HOST_PATH}/lib/cmake
is a valid path on disk and use that. This is nicer to the user
because they don't need to specify 2 paths anymore.
Furthermore the path computation and sanity checks are now done after
any extra toolchain cmake files are loaded, to give an opportunity
to the files to set the paths first.
Finally, both variables need to be added to
__qt_toolchain_used_variables so they are passed along to try_compile
calls if the variables are specified manually.
Otherwise when the toolchain file is loaded by a try_compile project,
it will error out saying no host path found (as long as the initial
paths embedded in the toolchain are invalid).
Amends 93fc3afe71 and
ec90f9013b
Pick-to: 6.2
Change-Id: I433239b36b084f2d0a7a0dd043fdf87d77c138f3
Reviewed-by: Craig Scott <craig.scott@qt.io>
One can now set QT_FORCE_FIND_TOOLS to ON together with passing a
QT_HOST_PATH to ensure that a new desktop build uses
already existing tools from a different Qt host (desktop) installation.
Depends on a0e56294c1
to work, which is not in 6.2, but this change is still included in
6.2 because it cleans up the conditions a bit to make them more clear.
Amends 42d3b21c92
and 5a779a4ad3
Pick-to: 6.2
Fixes: QTBUG-95099
Task-number: QTBUG-97658
Change-Id: If6258fb1091c6c1e457f22ae5f468b811bd20d57
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross-building, qt_internal_add_tool would accidentally find device
QtFooTools CMake packages as a result of calling find_package. It should
have found host Tools packages instead.
The reason was due to a combination of setting
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH, find_package preferring
the lookup of packages in CMAKE_FIND_ROOT_PATH before CMAKE_PREFIX_PATH
and there being a Tools package in the device sysroot.
Because qt_internal_add_tool didn't adjust CMAKE_FIND_ROOT_PATH to
contain the host path, the device package was picked up.
Change the implementation not to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
and instead modify both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH
to prefer the host packages instead.
This aligns to the behavior that was introduced in
ec90f9013b
which is used in QtModuleDependencies when looking for Tools packages.
Pick-to: 6.2
Fixes: QTBUG-97599
Change-Id: I8e38284774ae97981ccfd5071465609f3de80f01
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building Qt repos, all find_package(Qt6) calls request a
PROJECT_VERSION version which is set in .cmake.conf via
QT_REPO_MODULE_VERSION.
This means trying to configure qtsvg from a 6.3 branch using a
6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3)
and no such Qt6 package version exists.
There are certain scenarios where it might be useful to try to do
that though.
One of them is doing Qt development while locally mixing branches.
Another is building a 6.4 QtWebEngine against a 6.2 Qt.
Allow to opt out of the version check by configuring each Qt repo
with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not
recorded and will have to be set again when configuring another
repo.
The version check will also be disabled by default when configuring
with the -developer-build feature. This will be recorded and embedded
into each ConfigVersion file.
If the version check is disabled, a warning will be shown mentioning
the incompatible version of a package that was found but that package
will still be accepted.
The warning will show both when building Qt or using Qt in a user
project.
The warnings can be disabled by passing
-DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE
Furthermore when building a Qt repo, another warning will show when an
incompatible package version is detected, to suggest to the Qt builder
whether they want to use the incompatible version by disabling the
version check.
Note that there are no compatibility promises when using mixed
non-matching versions. Things might not work. These options are only
provided for convenience and their users know what they are doing.
Pick-to: 6.2
Fixes: QTBUG-96458
Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422
Reviewed-by: Craig Scott <craig.scott@qt.io>
Tests for QNX are run in qemu over ssh and setting WORKING_DIRECTORY
will cause created test wrapper to try change specified directory
which will fail (expects local directory) when test is invoked over
ssh.
Task-number: QTBUG-87628
Pick-to: 6.2
Change-Id: If991002398811cc9cb9cbac54da5d2cb0d8c3589
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
GNetworkMonitor can get information from 3 sources:
* org.freedesktop.portal.NetworkMonitor
* NetworkManager
* netlink
Change-Id: Icfafe6af42148f26360449f1262093ffc6b0613a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The previous implementation would pick up static Qt deps of a
shared Qt library as packages to find, but packages are not
created for these static libraries in a shared Qt build.
For example Qt::BundledSpirv_Cross is a static helper lib
that is linked directly into ShaderTools shared lib and no CMake
package is created for it, so we shouldn't look for it.
Separate the code path to filter out private dependencies
of a shared library target that don't have packages.
Amends 87215c70c0
Pick-to: 6.2
Fixes: QTBUG-97673
Task-number: QTBUG-86533
Change-Id: I43490b4d20c150256ccfa8b511a6e0e6b0f4b313
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Private Qt module dependencies of a Qt module are recorded
in the IMPORTED_LINK_DEPENDENT_LIBRARIES property of a Qt module.
This property is used to compute the runtime dependency dir path
to be passed to the linker via the -rpath-link option.
If the referenced target does not exist in the scope where it's
used, no -rpath-link will be generated (or at least that specific
dir path won't be passed).
The linking operation will either fail saying the library is not found,
or a different version of the library might be silently picked up in
the sysroot or other implicit lib dir.
Make sure that QtFooModuleDependencies.cmake calls find_package() for
all Qt module private dependencies (or other Qt provided 3rd party
libs in the Qt6:: namespace) so that the targets are in scope and
IMPORTED_LINK_DEPENDENT_LIBRARIES does its job.
qmake also records the INTERFACE_LINK_LIBRARIES of a private Qt module
as the runtime dependencies of the module.
It's not clear why it does that. A private Qt module is an
INTERFACE_LIBRARY so it shouldn't add any new runtime dependencies.
Nevertheless, the find_package part of that has been recently addressed
in 2b6500cd15 for a different reason.
This change is basically the CMake equivalent of
326b91ea78
Pick-to: 6.2
Fixes: QTBUG-86533
Change-Id: Iaf514a14acaded4e8752149cca0c159a271be188
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The constructor from a raw pointer should be
1) constexpr,
2) explicit, and
3) *private*.
We can do 1) without too much trouble.
2) is a (easy to fix) SIC in case of implicit conversions accidentally
relied upon from somewhere.
3) cannot be "easily" fixed by user code (they have to refactor), and
also, it's a BIC on Windows which encodes class members' access in
symbols. Someone may have been exporting some QList subclass, in turn
exporting the iterator classes, and therefore that someone now has the
constructors' symbols with a given access.
So, don't do 2+3 _just yet_ for user code, but set a deadline: Qt 6.5 is
the last that will support this. On Qt 6.6, we switch. All of this on
non-Windows, againt to avoid an ABI break. One can opt-in at any time
via a suitable define.
Given we have this define, use it to guard the other way around as well:
conversions from an iterator to a raw pointer should never be explicit
(there's std::to_address for this).
[ChangeLog][QtCore][QList] Converting a QList's iterator from and to a
raw pointer is deprecated, and will get removed in Qt 6.6. User code can
prepare for the change by defining QT_STRICT_QLIST_ITERATORS.
Change-Id: I0f34bfa3ac055c02af5a3ca159180304660dfc11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Each included qml Qt6FooPluginTargets.cmake file checks whether
all the dependency targets that are referenced in the file already
exist by the time the file is included.
If one of the referenced targets is missing, the file sets
${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE with a message mentioning
which targets are missing and also sets
${CMAKE_FIND_PACKAGE_NAME}_FOUND to FALSE.
All our qml package Config.cmake and Targets.cmake files are
include()d by Qt6QmlPlugins.cmake using a file(GLOB) which means the
order in which the files are loaded is implementation-defined.
Furthermore we didn't check the above set variables after each
inclusion, which means the values are overridden and the last plugin
to be loaded determines whether the Qml package is found or not.
If the last included file sets no error, it effectively silences any
previously set error.
Ever since we added dependencies between the qml plugin targets
themselves, we hit the above situation and depending on the platform,
no error was shown because the last file overrode any errors.
But we finally got a specific platform (wasm) which unearthed the
problem (QTBUG-97478). This can happen for any static Qt build though.
To fix this properly, we will most likely have to rewrite the whole
inclusion mechanism to use find_package() so that dependencies
can be resolved recursively as needed. This is a non-trivial change
that will have to be addressed in both qtbase and qtdeclarative.
In the mean time, a stop-gap solution that this change implements is
to include all the files while ignoring any error messages.
Then include the files one more time and check for error message after
each included file.
All qml plugin targets should have been brought into scope with the
first round of inclusions, thus circumventing "missing referenced
target" errors, while still catching any other possible errors.
Amends
6fd1216801f078f65be2cbc748cc459cb6912a4f
9fc302e6d146878103b3d105dce49c7695fcf93a
c368175a9e0a0c120b5bb8a0a02859bfc0cf42ba
in qtdeclarative.
Pick-to: 6.2 6.2.1
Fixes: QTBUG-97478
Task-number: QTBUG-95609
Task-number: QTBUG-97099
Change-Id: I157fa93fc979d726cd221d969b995b3642aeec77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
PRIVATE_MODULE_INTERFACE libraries are linked as interface libraries to
the module's Private target and exported as the dependencies of package
targets. We need to register these modules as public package dependencies
to call find_package when resolving module dependencies in user
projects.
Pick-to: 6.2
Fixes: QTBUG-96558
Change-Id: I4eef550aab306eaf357539ef7a0f76d69873f856
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
file(GENERATE) might fail if an unrelated configuration error happens,
and yet QT_TOOL_COMMAND_WRAPPER_PATH would already be set. Set the
cache variable only if generating was successful and replace the
QT_TOOL_COMMAND_WRAPPER_PATH valiable check with GLOBAL property to
protect the function from double call.
For CMake versions higher than or equal to 3.18 replace 'file(GENERATE'
call with 'file(CONFIGURE' to generate the wrapper at configure time
with the use of a plain semicolon character.
Pick-to: 6.2
Fixes: QTBUG-96870
Change-Id: Icf9c40f571d9c069043604f67ffcf2762966f6d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When building Qt we need to set QT_ANDROID_ABIS value to
CMAKE_ANDROID_ARCH_ABI explictily since the automatical detecting of
android ABI is not executed. This fixes build of the qtbase in-tree
tests.
Fixes: QTBUG-97133
Change-Id: Ica7057bcfcc8f4fe4b5a921ca7449f74cdbca0f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We don't need to check FEATURE_ltcg, just add -fno-lto unconditionally.
That makes QtCore compile with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON.
Change-Id: Icb2516126f674e7b8bb3fffd16ada2c71d7334aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes a few cleanups to our .cmake files where it was easier to
combine existing sections of Clang / AppleClang that no longer needed to
be distinct.
icpx could be replaced with a shell script:
exec `basename $0`/clang++ --intel "$@"
tst_qnumeric is not passing
FAIL! : tst_QNumeric::classifyF() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::classifyD() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 4194304
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 2251799813685248
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
P
Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MoltenVK installed from homebrew has the following
directory structure:
molten-vk/1.1.5/libexec/include/vulkan/vulkan.h
molten-vk/1.1.5/include/MoltenVK/mvk_vulkan.h
Task-number: QTBUG-80576
Pick-to: 6.2
Change-Id: If6f5aeb55908f60fff49417ee1ddf4c2db980c5a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten complains that this variable is deprecated and should be
replaced with the one given in this patch.
Change-Id: Iafee06fcb1f292de25570545d74d7327679461b0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This define used to be set for the entirety of the Qt build but
was lost during the qmake->CMake transition. Re-enable it.
Change-Id: Idc4cb6ada485158559485b60f62f76439550b255
Pick-to: 6.2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This amends commit 165e01d5d5.
Above commit broke the code that adds "${PROJECT_SOURCE_DIR}/cmake" to
CMAKE_MODULE_PATH. The semicolon that separates entries of
CMAKE_MODULE_PATH must be escaped. Otherwise, the semicolon separates
elements of the flags list.
Additionally, fix the QT_AVOID_CUSTOM_PLATFORM_MODULES code path which
lacked the addition of "${PROJECT_SOURCE_DIR}/cmake".
Pick-to: 6.2
Change-Id: I72f78cf066cabe6b0002dce1aa0294aa0dc9cbf0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not read the target property LINK_LIBRARIES from interface libraries
as this leads to errors with CMake 3.16.
This amends commit 326b91ea78.
Pick-to: 6.2
Change-Id: I44251c7633d5ecd977cd05746ac311dd1285d1e3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The .pri files for public Qt modules were missing run_depends entries.
Those entries are used by qmake when linking plugins of a static Qt
build. In shared builds, run_depends entries are used to decide whether
to add the -rpath-link argument to the linker. In that matter,
run_depends entries serve a similar purpose as CMake's
IMPORTED_LINK_DEPENDENT_LIBRARIES.
In Qt5, run_depends entries consist of the qmake values QT_PRIVATE and
QT_FOR_PRIVATE.
QT_PRIVATE contains the Qt modules that are privately linked to the
public module, and QT_FOR_PRIVATE are the dependencies of the private
module. That loosely translates to LINK_LIBRARIES of the public module
and INTERFACE_LINK_LIBRARIES of the private module.
Private modules whose public counterparts are already public
dependencies don't have to be added to run_depends.
Pick-to: 6.2
Fixes: QTBUG-84310
Change-Id: If7025c98ea462a2d5a143202df3d98d88e4fee08
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since commit f3c7d22dd0 we do not use
libraries from /usr/local and other non-system locations on macOS. But
our configure tests still did. This led to discrepancies between
find_package calls in configure tests and the Qt project itself.
Mentioned commit removed /usr/local and friends from
CMAKE_SYSTEM_PREFIX_PATH. But we can't pass this variable to the
configure tests, because CMake sets it up and overwrites our value.
Pass CMAKE_SYSTEM_PREFIX_PATH and CMAKE_SYSTEM_FRAMEWORK_PATH as
QT_CONFIGURE_TEST_CMAKE_SYSTEM_{PREFIX|FRAMEWORK}_PATH variables to
tests.
Tests with separate project files that call find_package() must add code
like this after the project() command:
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH)
set(CMAKE_SYSTEM_PREFIX_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH}")
endif()
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH)
set(CMAKE_SYSTEM_FRAMEWORK_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH}")
endif()
Adjust pro2cmake accordingly.
Task-number: QTBUG-97076
Change-Id: Iac1622768d1200e6ea63be569eef12b7eada6c76
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When passing an absolute input file name to qlalr, the #line directives
in the output will contain absolute paths. For reproducible builds,
it's desirable to have relative paths.
Pass the input file as relative path to qlalr to produce relative #line
directives.
Fixes: QTBUG-96267
Change-Id: I4ef1e4d5be7cbaf25a54a34ab7c2dbec06411a1d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain platform-related variables, in this case UNIX, must be set in a
platform module, because they get cleared after the toolchain file is
loaded. Such platform modules live in upstream CMake, but there is none
yet for INTEGRITY. This manifests in an undefined UNIX variable and
"System is unknown to CMake" warnings for the project and every
configure test.
Add the CMake module "Platform/Integrity" in the cmake/platforms
directory. Add this directory to CMAKE_MODULE_PATH to let CMake load
Platform/Integrity when the toolchain file set CMAKE_SYSTEM_NAME to
"Integrity".
CMake's module directory takes precedence, when loading platform
modules. This is special for platform modules and different from the
documented behavior of CMAKE_MODULE_PATH and include().
In case the user wants to provide their own platform modules via
CMAKE_MODULE_PATH, they can instruct Qt to not add its path by setting
QT_AVOID_CUSTOM_PLATFORM_MODULES to ON.
Make sure that configure tests with project files also load the custom
platform module.
Pick-to: 6.2
Fixes: QTBUG-96998
Change-Id: I9855d620d24dc66353cec5e847a2675b464ace26
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Emscripten only supports
SSE1, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, and 128-bit AVX instruction
sets at this time.
https://emscripten.org/docs/porting/simd.html
Browsers might need to enable simd support in the advanced
configurations
about: config or chrome:flags
Enable by configuring Qt with -sse2
Pick-to: 6.2
Fixes: QTBUG-63924
Change-Id: Ifeafae20e199dee0d19689802ad20fd0bd424ca7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
We don't have any APSPI2 includes in our public headers and should
therefore not export the target that provides ATSPI2 include paths for
consumers.
Link against PkgConfig::ATSPI2 instead of the _nolink target.
The former will not be exported.
Pick-to: 6.2
Fixes: QTBUG-97023
Change-Id: I4b12e0c2230917feeb963c02565e6db24f757bd3
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
QDoc modifies its linking behavior depending on whether the -installdir
command line option was set or not; Without -installdir, QDoc will
use 'https://<url>' to link to targets loaded from external
documentation modules, instead of using relative paths.
Drop the -installdir if QT_BUILD_ONLINE_DOCS was set. This behavior matches
the 'build_online_docs' scope that was used for qmake documentation
targets, and is useful for documentation projects that are not part of
Qt but want to link to Qt docs simply by loading the index files of Qt's
modules.
Pick-to: 6.2
Change-Id: Ib1bbf7b9d784e0c276d2bc520240af4a6c8ba903
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The device prefix in target_qt.conf is necessary if and only if the
prefix on the host is different from the prefix on the device - in CMake
terms: if CMAKE_STAGING_PREFIX is different from CMAKE_INSTALL_PREFIX.
This removes the [Devices] section from target_qt.conf from our iOS and
Android packages, because we don't set CMAKE_STAGING_PREFIX for those
platforms.
Pick-to: 6.2
Fixes: QTBUG-96906
Change-Id: I1390e952e544e57d5dd3bc09d688a612db9b4247
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The separate_debug_info configure test uses the CMake variable
CMAKE_OBJCOPY. CMakeFindBinUtils in the test project finds the host's
objcopy despite CMAKE_TOOLCHAIN_FILE being correctly set.
We now add CMAKE_OBJCOPY to the list of variables that are passed to
configure test projects and remove the CMakeFindBinUtils include, which
looks rather internal anyways.
Pick-to: 6.2
Fixes: QTBUG-96798
Change-Id: I164c6bd1771e8789e9dd19b50573b33b8866bd3b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rather than fail with obscure can't find Qt packages errors when the
Webassembly CMake toolchain file can not be found, error out with a
clear error on how to ensure it is found.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: I0f34cdcde05efb25c93017f3fd365186335ed52c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Try to to chainload the emscripten CMake toolchain file from the
EMSDK env var if it is set, instead of requiring the user to explicitly
specify a path to the file via QT_CHAINLOAD_TOOLCHAIN_FILE.
The order in which the toolchain file is chainloaded becomes is as
follows:
1) The initial toolchain file path that was specified when configuring
qtbase is set written as the initial value of
__qt_chainload_toolchain_file in qt.toolchain.cmake
2) If EMSDK env var is set, it overrides the value from 1)
3) If QT_CHAINLOAD_TOOLCHAIN_FILE cache var is supplied it overrides
the value from 2)
Whichever value ends up in __qt_chainload_toolchain_file is
checked too see if the file exists.
If it exists it gets included, if it doesn't, a warning is issued.
This checking logic is a bit crude and should be improved and unified
with the Android chainload checking, but the current change already
improves the behavior for users of Qt.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: I5da58a329f659086aaaee765c9399d0369021b22
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Split qt_auto_detect_wasm into multiple helper functions and place
them in a new QtPublicWasmToolchainHelpers.cmake file.
We want to use them to try and detect the CMake toolchain
file location from within the generated qt.toolchain.cmake
file whem configuring a user project.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: Id8c2350e6dbe3c994b435681353bdaee114249a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a new macro qt_internal_return_unless_building_tools which
simply calls return() if tools are not built. This macro is supposed to
be called after qt_internal_add_tool().
Using this macro avoids having to special-case code for when
qt_internal_add_tool() creates imported targets in cross-builds.
Adjust pro2cmake accordingly.
Task-number: QTBUG-85084
Change-Id: I9e1c455c29535dd8c318efa890ebd739c42effc1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for subsequent change that will check and error out if the
version is lower than 3.16. We do that to ensure all policies
introduced by CMake up to version 3.16 have their behavior set to
NEW.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Ieaf82c10987dd797d86a3fd4a986a67e72de486a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
In non-prefix builds, we want to prevent users from accidentally running
"cmake --install". We did that by replacing cmake_install.cmake with an
empty file.
The responsible target remove_cmake_install is visible in IDEs, appears
in the build output, and the approach is hacky.
It's cleaner and easier to add bail out code at the top of
cmake_install.cmake. This is now done when calling qt_build_repo_begin.
As a bonus, print an informative message on installation.
Change-Id: I022b36289358ba09cac8b79781f44cd7b93113f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When setting QT_FEATURE_ values we need to convert the user-provided
FEATURE_ values to the one that is supported by QT_FEATURE_.
Pick-to: 6.2
Fixes: QTBUG-96300
Change-Id: Idd19fbf7f23f351a6c1cfdcedccfaaf6b0aa6e44
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CMake doesn't add framework include paths for the includes if
add_custom_command is used. When all Qt modules are installed to a
single directory, frameworks could be found under
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX, but for Conan builds
each module is installed to the separate directory. These directories
need to be listed in the QT_ADDITIONAL_PACKAGES_PREFIX_PATH variables
family. This takes into account directories that are listed in the
QT_ADDITIONAL_PACKAGES_PREFIX_PATH variables and considers they
can contain frameworks.
Pick-to: 6.2
Fixes: QTBUG-96511
Change-Id: I664381df4859a2e85c399cd94dc2f3996e452c03
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This fixes the detection of always available architecture based on
user set CMAKE flags.
Change-Id: I541ac9569766a0fe05f4395c06f2ee3bcd77b035
Fixes: QTBUG-91090
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A recent change refactored the call to qt_internal_add_executable(),
but that had the unintended side-effect of changing the symbol
visibility from public to hidden. That meant that main() became hidden,
so while apps still built successfully, they could not be run. Restore
the original symbol visibility to fix this regression.
Amends d47278fd09
Pick-to: 6.2
Change-Id: I27d84ab2b0dd013d5c38dcfe55e88f307c4bc5dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EXE_FLAGS option wasn't being used anywhere in any Qt repo
and it had no documentation as to its intended use. Remove it.
Pick-to: 6.2
Change-Id: I2f67ec57c1da7dc6eab81d5351361e770d19d7d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These TODOs were left as a marker to be checked once the official
CMake 3.21.0 release was made. The things they refer to were included
in the CMake 3.21.0 release, so the TODOs can be removed.
Fixes: QTBUG-94528
Pick-to: 6.2
Change-Id: I769605de85df657ad056123e787ec9849b77e42f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Static libraries don't need to export their symbols, and corner cases
when sources are also used in shared libraries, should be handled
manually.
Task-number: QTBUG-90492
Change-Id: I5cb0a3f7e280b042b678bdbe4475f2bbf9f6b9ba
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If qt_internal_generate_cpp_global_exports is called outside the
qt_internall_add_module function scope, install rule that is
generated by qt_internall_add_module won't include generated
cpp export header files. This adds the explicit file-based install
rule for the generated cpp exports.
Since qt_internal_generate_cpp_global_exports now encapsulates all
install rules related to the generated cpp exports, no need to expose
the generated filenames outside the function.
It's expected that module public headers now could be added outside
the qt_internal_add_module function. Tune generating of the module
timestamp by replacing the DEPENDS value with generator expression.
Task-number: QTBUG-90492
Change-Id: I0f086abc8187c5d51117c3a75c47b58580f6913f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The _qt_is_android_executable property is normally set by the
_qt_internal_create_executable() command. But various other internal
commands don't route through that and go through
qt_internal_add_executable() instead. The former is used only by the
public API, the latter only by the internal API. Refactor both so that
the internal one calls the public one. This ensures all targets receive
the same base settings, including the _qt_is_android_executable
property.
Fixes: QTBUG-96085
Pick-to: 6.2
Change-Id: I157356872c9d942d7be5f1abbbcbac97961b1f40
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Conan CI builds can built a qt repository in a repo-target-set
configuration. An example of that is qtscxml.
When building standalone tests, qt_build_tests includes a repo
specific TestsConfig.cmake file to call find_package on the modules
that were built as part of that repo.
That doesn't quite work with a repo-target-set build which is enabled
when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value.
The TestsConfig.cmake file would be overridden with different contents
on each configuration.
Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as
part of the TestsConfig.cmake file to be generated and included.
This means that when configuring the standalone tests, the same
QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the
correct packages are found.
Add some debug statements to allow checking which TestsConfig.cmake
file is loaded when the standalone tests are configured with
--log-level=DEBUG.
Adjusts to 4b09522c23
Amends de3a806def
Amends e7f188b2d2
Pick-to: 6.2
Task-number: QTBUG-96253
Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Functions that use qt_internal_add_module under the hood might need to
generate cpp exports, e.g. qt_internal_add_qml_module. Append cpp
exports related arguments to the qt_internal_add_module arguments set.
Task-number: QTBUG-90492
Change-Id: I4fd539bd1d8be4d3e57ed5b1b88dd2dbc2f5ca24
Reviewed-by: Craig Scott <craig.scott@qt.io>
Because otherwise we may end up with trailing backslashes
Pick-to: 6.2 6.2.0 6.1
Change-Id: I7ad24ec34c35f0a7b32241751bbcd2b26a8a23ea
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Propagating of plugin init libraries should take into account
plugin finalizers to avoid duplicating of object files in a linker
line.
Pick-to: 6.2
Fixes: QTBUG-96062
Change-Id: I48feac94b08a7eb08d84134e9e9ae6e7214f5bdd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The variable might be defined to HOST_PERL-NOTFOUND which will return
early instead of issuing an error.
Change-Id: Id49dfd0fec8f477dad9e816e6128e36059e68702
Pick-to: 6.2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We default to configuring examples as separate ExternalProjects when
using a developer / non-prefix Qt build.
This ensures we test that the examples configure successfully without
the pollution of the main Qt build (e.g. already found packages).
One down-side of this is that a developer's IDE doesn't see these
example targets, unless each project is loaded into the IDE
separately. This is cumbersome to do when refactoring or renaming
code across multiple example projects.
Allow configuring the example projects as part of the main Qt build
by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt.
Save the value of the variable in QtBuildInternalsExtra.cmake.in
so it's propagated to leaf repositories as well.
Amends dab8f64b6d
Amends d97fd7af2b
Task-number: QTBUG-90820
Task-number: QTBUG-94608
Task-number: QTBUG-96232
Task-number: QTCREATORBUG-26168
Pick-to: 6.2
Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There is no need for this variable to be stored in CMake's cache. We
don't perform expensive operations to set up QT_SYNCQT, and we even
unset the cache variable to ensure it gets recomputed on
reconfiguration.
We still store QT_SYNCQT in a global property, because the function
qt_ensure_sync_qt is called in different directory scopes, and we want
to avoid re-calculations for every subdir.
It's now possible for the user to set QT_SYNCQT (see QTBUG-88088 for
motivation). Also, in a non-prefix build, changes to syncqt.pl in the
source dir are reflected upon re-configuration in the build
tree (because qt_copy_or_install is called on every configure).
Pick-to: 6.2
Fixes: QTBUG-88088
Task-number: QTBUG-75290
Change-Id: I6137b060d200d3dafd4a64d5a6c1bd2549723d78
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
By the time of Qt 6.2 release all new apps targeting Play store must
target API level 30 (Android 11) or above (starting in 08/2021 for
new apps and 11/2021 for existing apps' updates).
Pick-to: 6.2 5.15
Task-number: QTBUG-94451
Change-Id: Id7fa2fd62899a7259e365c917292c6c3ac0d2b0d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Before, we would just issue a warning which is likely to get overlooked
in CMake's output. Also, the configure summary would report "Using
ccache ... yes" but CMAKE_<LANG>_COMPILER_LAUNCHER stays unset, which is
inconsistent.
Make QT_USE_CCACHE=ON and missing ccache a hard error.
Task-number: QTBUG-88308
Change-Id: Iddc7f3a91428fd96ad0defbb1ca72bd46a90aa98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -static argument we used before is supported by ld, but not lld.
The latter requires --static or -Bstatic. Use -Bstatic, which is
supported by both.
Pick-to: 6.2
Fixes: QTBUG-89549
Change-Id: I3c3069661bf4cd20e3298aff4714163b7419d3ef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the generating of private cpp exports for Qt modules.
Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module
that is the manual switch for private exports generator. Existing
modules in qtbase doesn't follow any strict convention of using
private cpp export. So there is no clue how to detect if generating of
the private exports is required or not for the module.
Use autogenerated private cpp exports in QtNetwork module.
CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function
is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different
meaning. The provided name is used as a base name for the private and
non-private headers that contains cpp exports. Header files suffixes
are constant: .h and _p.h for the non-private and private header files
accordingly.
Pick-to: 6.2
Task-number: QTBUG-90492
Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Module may have specific module include name that should be taken into
account when specifying module include directories in different places.
The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to
the common naming rules and the property is used to preform include
paths instead of the direct use of the module name.
Add additional paths generated by qt_internal_module_info to keep them
consistent across all cmake files.
Pick-to: 6.2
Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Warn if the PRIVATE_MODULE_INTERFACE option is provided a value, but
there is no ${target}Private target to set the interface dependencies
on.
Pick-to: 6.2
Task-number: QTBUG-95921
Change-Id: I7d4df9cb3aa9b7746d836b82019ecdd9c8f50fdc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Don't export the MODULE_PLUGIN_TYPES property only when a module has
an associated configure.cmake file with features. Instead, always
export it if a module defines a plugin type.
This fixes qttools DesignerTargets.cmake file to contain the plugin
types it defines, given that the Designer lib does not declare any
features via a configure.cmake file.
Pick-to: 6.2
Task-number: QTBUG-95668
Change-Id: Ic036c31768e03b51d3bce9c2afe48e04f69f435b
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To detect the internal module ouside the qt_internal_add_module
function need to mark it with the property.
This adds _qt_is_internal_module property to the Qt internal modules.
Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private
modules, INTERNAL_MODULEs is missing those dependencies if they were
specified. Add extra condition to qt_internal_extend_target to link
PRIVATE_MODULE_INTERFACE libraries to internal modules as well.
Pick-to: 6.2 6.1
Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously we only created object library static plugin initializers
for Qt plugins only, not user-project plugins.
The reason was that if a user tried to install the plugin target via
an export set, CMake would error out saying that the _init library is
not part of the same export set.
Introduce an OUTPUT_TARGETS option that would allow projects to get
the name of the generated _init target, so they can install it if
needed.
This was already done for qt6_add_qml_module, so we just introduce the
same option for qt6_add_plugin.
Now user static plugins will have an _init target created, which will
be propagated to consumers whenever the consumers link against the
plugin itself.
We also need an internal option to disable this propagation, because
it's handled a bit differently for Qt plugins which can be linked
either via finalizers or via usage requirements.
Amends 91c65dd80c
As a result of the implementation change, cleanup example projects
to ensure that they build successfully (the important part is
specifying the CLASS_NAME).
Only plugandpaint works properly with both shared and static Qt
builds.
echoplugin works with a shared Qt build, but not a static one due to
some assumptions in the C++ code about shared plugins.
styleplugin doesn't seem to work properly neither with shared Qt
builds nor static Qt builds, at least on macOS. But it builds fine.
For some reason even if the plugin is found, the style is not applied.
Amends 4caac1feea
Pick-to: 6.2
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb
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>
Do not add catch-all header files like QtCore, QtGui, etc. to
precompiled headers for targets that already define their own set of
precompiled header files.
This reduces the size of the precompiled headers and brings the pch file
sizes down into the region of the qmake build.
Pick-to: 6.2
Task-number: QTBUG-89122
Change-Id: I8e4d17aa6829c7d7b1aa01a01a61b6677e22c460
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now it's possible to display a configure help screen per module with
qt-configure-module <module-source-dir> -help
Pick-to: 6.2
Fixes: QTBUG-95943
Change-Id: I7d26006246af4b38b5a2ec6deca3f45c5313afec
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a preparation for adding the -help argument to
qt-configure-module.bat.
Consider the call
qt-configure-module.bat path/to/qt-module -help
Internally, we called
cmake ... -P .../QtWriteArgsFile.cmake path/to/qt-module -help
which was supposed to separate the arguments and write them into
config.opt.
However, passing arbitrary arguments after "-P script.cmake" only worked
by accident and is not supported. As soon as arguments are passed that
are valid CMake arguments, like -help or -G, the CMake call would fail.
Now, we let configure.bat and qt-configure-module.bat write the
arguments as is into config.opt.in and let QtWriteArgsFile.cmake read
this file, separate the arguments and write config.opt.
Pick-to: 6.2
Task-number: QTBUG-95943
Change-Id: I80f298a2aaf55b0f79fed86320a055eb2d2b6faa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 64c111e10f.
The claim of the commit message, that we cannot use the gold linker,
does not seem to be true (anymore?). This is underlined by the fact
that CMake *forces* the gold linker for Android, whenever LTCG is
enabled (see Modules/Compiler/Clang.cmake as of CMake 3.21.1).
Change-Id: I90edac8555be4abdd44cd367228aeffb0d66b895
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We're passing -Oz for release builds, but that's not a flag the linker
understands when -ltcg is enabled. The build fails with:
ld.gold: fatal error: Optimization level must be between 0 and 3
Fix this by using -O2, which -Oz is based on, and -O3 for the "full
optimization" that is used for core and gui.
Pick-to: 6.2
Fixes: QTBUG-89472
Change-Id: Ie1a86888baefce5ca97026e7d635f10d2819f9f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Pass Qt6_FIND_VERSION to components when the
find_package(Qt6 ${ver} COMPONENTS Foo) signature is used.
Create a ConfigVersion file for BuildInternals, so that BuildInternals
passes the version check.
Fix qt_configure_file to look in the _qt_6_config_cmake_dir folder for
the template file rather than Qt6_DIR, because Qt6_DIR might be
accidentally unset after a failed find_package(Qt6) call and the error
is not helpful then.
We already pass versions everywhere else when looking for
dependencies, like in ModuleDependencies.cmake.in,
PluginDependencies.cmake.in, ModuleToolsDependencies.cmake.in.
Pick-to: 6.2
Fixes: QTBUG-91737
Change-Id: Ief1da0c6f239c935385e7ce662951e85ccfdf130
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The QT_ADDITIONAL_PACKAGES_PREFIX_PATH variable was introduced to
allow specifying extra locations to find Qt packages.
The reason it was introduced instead of just using CMAKE_PREFIX_PATH
is because the Qt6 component find_package call uses NO_DEFAULT_PATH
which means CMAKE_PREFIX_PATH is ignored.
We use NO_DEFAULT_PATH to ensure we don't accidentally pick up
system / distro Qt packages.
The paths from QT_ADDITIONAL_PACKAGES_PREFIX_PATH are added to the
find_package PATHS option in the Qt6 package, each
ModuleDependencies.cmake file and some other places.
Unfortunately that's not enough to make it work for cross-builds.
Imagine the following scenario.
host qtbase, qtdeclarative installed in /host_qt
target qtbase installed in /target_qtbase
target qtdeclarative installed in /target_qtdeclarative
We want to cross-build qtlottie.
We configure qtlottie as follows
/target_qtbase/bin/qt-configure-module /qtlottie_src -- -DQT_ADDITIONAL_PACKAGES_PREFIX_PATH=/target_qtdeclarative
We expect the target QtQuick package to be found, but it won't be.
The reason is that QT_ADDITIONAL_PACKAGES_PREFIX_PATH is added to the
PATHs option, but we don't adjust CMAKE_FIND_ROOT_PATH.
Without adding the new paths in CMAKE_FIND_ROOT_PATH, CMake will
re-root the passed PATHs under the existing CMAKE_FIND_ROOT_PATH,
which is QT_TOOLCHAIN_RELOCATABLE_INSTALL_PREFIX, which evaluates to
/target_qtbase. There is no QtQuick package there.
To fix this, prepend the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to CMAKE_FIND_ROOT_PATH.
The location where we currently do CMAKE_FIND_ROOT_PATH manipulations
is in the qt.toolchain.cmake file, so to be consistent, we prepend the
new prefixes there as well.
We need to adjust both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH,
due the path re-rooting bug in CMake.
See https://gitlab.kitware.com/cmake/cmake/-/issues/21937 as well as
the existing comment in qt.toolchain.cmake marked with
REROOT_PATH_ISSUE_MARKER.
We also need to do a few more things to make the setup work
Because Qt6Config uses NO_DEFAULT_PATH, the CMAKE_PREFIX_PATH
adjustments we do in the toolchain file are not enough, so we still need
to add the same prefixes to the Qt6Config find_package PATHS option.
One would ask why do we need to adjust CMAKE_PREFIX_PATH at all then.
It's for find_package(Qt6Foo) calls to work which don't go through
the Qt6Config umbrella package.
To make the CMake re-rooting behavior happy, we need to ensure the
provided paths are absolute.
So we iterate over the values of QT_ADDITIONAL_PACKAGES_PREFIX_PATH,
to make them absolute. We do the same for the environment variable.
We need to append lib/cmake to the prefixes which are added to
CMAKE_PREFIX_PATH, otherwise the CMake re-rooting bug is hit.
We need to specify the Qt6 package location (${_qt_cmake_dir}) to the
PATHS option in the various Dependencies.cmake.in files, to ensure
that dependency resolution can jump around between the Qt6 dir and
the additional prefixes. Previously the dependency lookup code assumed
that all dependencies would be within the same prefix.
The same is needed for qt and qml plugin dependency lookup.
Amends 7bb91398f2
Amends 60c87c6801
Amends 5bbd700124
Pick-to: 6.2
Fixes: QTBUG-95854
Change-Id: I35ae82330fec427d0d38fc9a0542ffafff52556a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is just a minor optimization.
Pick-to: 6.2
Change-Id: Icf0fc615895e1def63c57a72694c89f7ae7ee5cf
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
_<module>_MODULE_DEPENDENCIES variable in the
<module>Dependnecies.cmake should only contain the list of targets that
module depends on, but not versions. Version of the first module
appears in the list because of the regression introduced in
425ff34aa1
Amends 425ff34aa1
Pick-to: 6.2
Change-Id: Iaa42120af6bac742bdf0f8d389bd8e5bdef9c1d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Installing extracted metatypes json files for user projects was an
oversight. We shouldn't install anything on behalf of user projects,
but rather give them enough information so they can do it the
themselves.
Make all the install options of qt6_extract_metatypes internal,
change the behavior not to install the files by default, unless
__QT_INTERNAL_INSTALL is passed, which is used for the Qt build only.
__QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from
projects.
This is behavior change for existing public API, but it's better to
fix this now before 6.2.0 release.
Introduce a new OUTPUT_FILES option to allow assigning the extracted
metatype file paths into a variable that the project provides.
The project can then install the files where they need them.
[ChangeLog][CMake] qt6_extract_metatypes does not install metatypes
files anymore. Instead the OUTPUT_FILES option can be provided to get
the list of extracted files for further processing.
Pick-to: 6.2
Task-number: QTBUG-95845
Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This will show packages that were found (or not) with
find_package(QUIET) in summary just before the configure summary.
It's useful for CI logs to determine whether some Qt packages was not
found when cross-compiling.
Pick-to: 6.2
Change-Id: Ic7d5062cf061f7c60b5c74374f957065dd8029f5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Let find_package(Qt6 COMPONENTS LinguistTools) for a cross-compiled
Qt fall back to search LinguistTools in the host Qt.
Use the same trick as in QtModuleDependencies.cmake: Prepend both
CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH with the QT_HOST_PATH
(respective ${QT_HOST_PATH}/lib/cmake).
Furthermore adding ${QT_HOST_PATH}/lib/cmake to PATHS argument
makes sure that find_package will work even with NO_DEFAULT_PATH.
Make sure not to match ShaderTools and Tools packages.
ShaderTools is the cross-compiled package, the host package name is
ShaderToolsTools.
Tools is the cross-compiled module from qttools.
Allow an opt out via a QT_NO_FIND_HOST_TOOLS_PATH_MANIPULATION
variable in case that we accidentally match more packages ending in
Tools that are actually cross-compiled packages.
Pick-to: 6.1 6.2
Fixes: QTBUG-95602
Change-Id: Ib0a787716fa529e36f22356da069e705d9eed5fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CFBundleLongVersionString Info.plist entry has been deprecated and
removed from Apple documentation for a long time now.
Remove it.
Pick-to: 6.2
Task-number: QTBUG-95838
Change-Id: I4e4f74e00d678fd67875976c8884a80cdbb8cec4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The value of QT_UIKIT_SDK is used in configure tests via
qt_config_compile_test -> qt_get_platform_try_compile_vars.
Up till now QT_UIKIT_SDK was only available in qtbase only.
Save the value in BuildInternals to ensure it's used for other repos
as well.
Change-Id: I46f372267782f1c8e7d48c237fe0264ac72d33bb
Pick-to: 6.2
Task-number: QTBUG-95838
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES
values with the ones Qt was configured with, when configuring a user
project with the Xcode generator and a single arch / sdk Qt build.
This ensures that calling xcodebuild from the command line chooses the
correct architecture and SDK when building the project.
Allow to opt out of this behavior by passing
QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT.
Amends 55a15a1c1b
Amends a6a3b82ffb
Pick-to: 6.2
Task-number: QTBUG-95838
Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The configure summary now suggests "ninja install" for Ninja
Multi-Config builds, because "cmake --install ." does not install all
configurations. See CMake upstream issue #21475.
Pick-to: 6.2
Change-Id: Ie3129a906945db9d09c6772ce66ec7239797b8fc
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing -DFEATURE_developer_build=TRUE did not add the define
QT_BUILD_INTERNAL to src/corelib/global/qconfig.h like
-DFEATURE_developer_build=ON would.
This happened, because the feature evaluation in
qt_evaluate_feature_definition did a string comparison against "ON".
Normalize both sides of the string comparison, and thus support all
booly values for features.
Pick-to: 6.2
Fixes: QTBUG-95732
Change-Id: Ibf03579c05919b35219438361fc93676b7cca7cc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building Qt for Android on Windows, the precompile_headers test
failed if the source directory was passed as absolute path without drive
letter. See CMake upstream issue #22534.
Work around the CMake issue by ensuring that the path is properly
prefixed with a drive letter.
Pick-to: 6.2
Fixes: QTBUG-95652
Change-Id: I3154b6c0bb2f53533306227074b24fbbf5973b05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The workaround of adding a drive letter to
QT_CONFIGURE_PREFIX_PATH_STR should be done when running on any
Windows host, not only when targeting Windows.
Amends 59c3be7117
Pick-to: 6.1 6.2
Task-number: QTBUG-87580
Change-Id: Ic6ca50aa58a4a54fb483e90fe61a907fe86cb002
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Debug tools are excluded from the ALL target for debug_and_release
builds. However, when using the -separate-debug-info option, the same
exclusion wasn't being applied for their dSYM INSTALL commands,
resulting in a CMake install error.
Pass any additional install args like
EXCLUDE_FROM_ALL COMPONENT "ExcludedExecutables"
to the installation rules of qt_enable_separate_debug_info and
install dSYMs for executables per-config in a multi-config build.
All the non-main config executable install rules are optional because
the non-main config executables are excluded from ALL.
Amends 5b136abd21
Pick-to: 6.2
Fixes: QTBUG-93999
Change-Id: I95c3ce28215c3ee535551e4b7a5fa9731f8f1c28
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
So that those values are used when configuring other repos in a
per-repo build arrangement.
Pick-to: 6.2
Change-Id: I5ff86260116c52afc87d7fcd5cbd047fcb9dde22
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The logic for linking plugins in a static build in Qt6*Plugins.cmake
looks up plugins that are named Qt6*PluginConfig.cmake, and the file
name is computed by the target name.
Not naming the target 'Plugin' therefore means it won't be picked up
in static builds.
Pick-to: 6.2
Task-number: QTBUG-95731
Change-Id: Ic83a29d7c91492c302eb413a69577a0c550e1a1b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
After introducing the _qt_module_has_headers target property, it's
better to replace the INTERFACE_MODULE_HAS_HEADERS use by
_qt_module_has_headers since properties duplicate each other.
Pick-to: 6.2
Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There can be cases where trying to incrementally rebuild an already
built Qt will cause a ninja dependency cycle error due to incorrect
dependency information created by AUTOMOC and AUTOUIC.
Example error when building qtscxml tests
ninja: error: dependency cycle:
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen/timestamp
->
auto/scxmlcoutput/default/ids1.h ->
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen ->
auto/scxmlcoutput/default/CMakeFiles/tst_scxmlcoutput_default_autogen
->
auto/scxmlcoutput/default/tst_scxmlcoutput_default_autogen/timestamp
Example error when building Qt Creator
ninja: error: dependency cycle:
src/shared/help/shared_help_autogen/include/ui_filternamedialog.h ->
src/shared/help/shared_help_autogen/timestamp ->
src/shared/help/shared_help_autogen/include/ui_filternamedialog.h
Warn and advise to use a different CMake version instead.
Pick-to: 6.1 6.2
Change-Id: I6f529ba6a526663bc6ed699b1bfe8a9094129887
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In top-level builds, when configuring qtsensors, the directory of
FindWMF.cmake isn't in ${CMAKE_MODULE_PATH}, this makes CMake couldn't
find WMF.
On Windows, QtMultimedia requires WMF. If WMF couldn't be found,
QtMultimedia will also be treated as NOT FOUND.
QtSensors has an optional dependency to QtMultimedia. If QtMultimedia
couldn't be found, CMake will warn.
Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6, to make sure these
files could be found by CMake.
Fixes: QTBUG-95655
Pick-to: 6.2
Change-Id: I87d14c9a7becd0ec493e00c297b2e01fc0ad0f96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Address TODO and use the new helper
__qt_internal_propagate_object_library function instead of
target_sources when linking static plugin initializers via usage
requirements.
Note that to work correctly this depends on using the
target_link_options object library linking approach, which means a
minimum CMake version of 3.17, which is already the case for static
Qt usage.
With CMake 3.21, it will use target_link_libraries approach instead.
With CMake version 3.16 or lower, currently, this won't work correctly
on Linux if there are dependencies wrapped in genexes because the
__qt_internal_propagate_object_library call will try to use
the still-by-default-enabled 'object_libraries' finalizer mode via
__qt_internal_collect_dependency_object_libraries and that stops
the usage of the target_sources approach to link the object files
directly.
This isn't a big deal though, because we already require CMake 3.20
as the minimum.
It might be a bigger deal if we will need any of this functionality
to work with 3.16 in shared Qt builds where the user project tries
to create and link against custom static plugins. But that's already
likely to be a can of worms even without this specific edge case.
Amends a37957df5c
Amends 91c65dd80c
Uses 3329212815
Pick-to: 6.2
Task-number: QTBUG-92933
Change-Id: I8710e79eee265d820f65c8ccc3d0bd0c0ee6eccd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qt6_enable_object_libraries_finalizer_mode is not needed anymore
now that static Qt builds require CMake 3.21 and thus CMake takes
care of placing object library object files at the beginning of
the link line.
Rename qt6_enable_import_plugins_finalizer_mode to a more generic
qt6_set_finalizer_mode that can enable or disable multiple
different modes.
For now the only available mode is "static_plugins" which handles
the behavior of the old function name.
The mode can be enabled by calling
qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins")
Note that the function is re-tagged as being in Technical Preview.
Ideally we would not need it at all. But we need to provide some
workaround for the limitations of linking Qt static plugins in CMake
on Linux-y platforms that use bfd ld or ld.gold.
The workaround does not work well with dependencies wrapped in
generator expressions which is why we can't confidently advertise it
as a proper solution.
Our hope is that this can be fixed in future upstream CMake versions
and the function can be removed.
See 6fcc272ac9 for details.
Adjust the tests due to the renamed and removed functions.
Amends 19e789bace
Amends cdbb390c4a
Amends a25027eecb
Amends 6fcc272ac9
Amends a3c430f390
Pick-to: 6.2
Fixes: QTBUG-95169
Task-number: QTBUG-95601
Task-number: QTBUG-95603
Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When CMP00126 is set to NEW, set(CACHE) doesn't remove regular
variable bindings with the same name as the cache variable.
This introduced an issue in qt_find_package, which called
find_package(CONFIG QUIET) to try and find a package config file, but
did not clean up the non-cache _FOUND variable which is automatically
set to 0 by CMake if no Config file is found.
Make sure to unset both the regular and cache _FOUND variables if either
the package config file was not found, or if none of the provided
targets found even if the Config file was found.
Also move the _DIR cache variable cleaning into the same code block.
Amends 4c31ce68d5
Amends 34b1c1c23c
Fixes: QTBUG-95635
Pick-to: 6.2
Change-Id: I871987217526e0f0a20038a8da52625838e49488
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake master / 3.22 introduced a behavior change in how conditions are
evaluated in the while command. It is now consistent with how if()
evaluates conditions.
This caused an issue in Qt code where a "(" opening parenthesis was
evaluated as part of the condition rather than as a string.
Fix this by wrapping the evaluation of the variable in quotes.
Pick-to: 6.1 6.2
Change-Id: I70c26dc91394f4a14f7a26419df264a069dc7dc5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
The -coverage argument merely added compiler flags for the Qt build. It
was never properly ported to the CMake build, and it doesn't seem
feasible to have configure arguments for every possible compiler option.
The same can be achieved by passing the needed compiler option to CMake,
for example: CMAKE_CXX_FLAGS=-fsanitize-coverage=trace-pc-guard
Pick-to: 6.2
Fixes: QTBUG-86227
Change-Id: Ieef9acaedc0a839f9fb35b4403395eea28643864
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The intention is to remove TYPE as a keyword completely before 6.2.0
release, but in case if that's not possible due to the large amount
of repositories and examples, just print a deprecation warning for
now and handle both TYPE and PLUGIN_TYPE.
Task-number: QTBUG-95170
Pick-to: 6.2
Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When Qt5Config.cmake was ported to Qt6, the assignment of
_Qt6_FIND_PARTS_QUIET was accidentally left out.
Make sure that when find_package(Qt6 QUIET COMPONENTS Foo) is
called, the underlying component find_package(Qt6Foo) call gets
a QUIET option as well.
This will silence short-form warnings like
-- Could NOT find Qt6Foo (missing: Qt6Foo_DIR)
It currently won't silence any warnings produced by the transitive
find_package calls in QtModuleDependencies.cmake. That will require a
separate change.
Remove usage of _Qt6_FIND_PARTS_REQUIRED which was always empty.
See details of QTBUG-95573 why it's currently not used.
Pick-to: 6.2
Task-number: QTBUG-95573
Change-Id: I3822c068eecbe84c306a1b04f4187278d35ec3d5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
This function is called by qt_add_executable. There is no need to
expose it as public function.
Fixes: QTBUG-95172
Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change introduces new behavior to error out when configuring user
projects if the CMake version used is too old for Qt to work with.
The main motivator is the requirement of new CMake features to ensure
object libraries are placed in the proper place on the link line in
static builds.
The minimum CMake version is computed based on whether Qt was
configured as shared or static libraries.
At the moment the required versions for building and using Qt are the
same.
The minimum versions are defined in qtbase/.cmake.conf in the
following variables
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC
Qt Packagers can disable the version check when configuring Qt
by setting
QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and
QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT.
In this case it is the packagers responsibility to ensure such a Qt
works correctly with the specified CMake version.
User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT
to disable the version check. Then it's the project's developer
responsibility to ensure such a Qt works correctly.
No official support is provided for these cases.
Implementation notes.
The versions required to build Qt are stored in
QtBuildInternalsExtra.cmake
whereas the versions required to use Qt are stored in a new
QtConfigExtras.cmake.
Also the policy range variables stored in
QtBuildInternalsExtra.cmake are now regular variables instead of cache
variables, to properly allow overrides per-repository.
Some renaming of functions and variables was done for a bit more
clarity and easier grep-ability.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Building a static library Qt configuration will now require a
minimum CMake version of 3.20.
Qt builders and packagers can still opt out of the mentioned minimum
required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION.
Such a Qt configuration is /NOT SUPPORTED/.
To facilitate these changes, the minimum version check has been moved
to happen after the BUILD_SHARED_LIBS option is computed by either
QtAutoDetect.cmake or set by a user provided cmake toolchain file.
Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable
in .cmake.conf to mark the minimum version for a static Qt build.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
The format was renamed in 27db9e458c.
Pick-to: 6.2
Change-Id: I53975c7467d8768dc9dc9ac2d89c42eefa12e22f
Reviewed-by: Mårten Nordheim <marten.nordheim@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 bb25536a3d
Amends 7b9904849f
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>
This fixes building Qt with Vulkan support on macOS which aside from
the regular Vulkan headers also needs the location of the MoltenVK
headers.
This assumes the usage of the LunarG Vulkan SDK for macOS.
Pick-to: 6.2
Fixes: QTBUG-80576
Change-Id: I030b2fdeaafdd7bf5ebe6fb4c9ea860917e84056
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Building a shared library Qt configuration already required a minimum
CMake version of 3.16, because we depend on CMake's Autogen.json files
which are used for metatype.json file generation.
If a lower version was used, a FATAL_ERROR was issued in
qt6_extract_metatypes.
This change is essentially moving the check to happen earlier in the
qtbase configure process.
User projects will now /also/ officially require a minimum of 3.16
(up from 3.14).
As a consequence, the min/max version policy range that is set in
the public QtFooConfig.cmake files is changed
from 3.14..3.19
to 3.16..3.20
The upper bound is raised because building and using Qt works fine
with all CMake 3.20 policies set to NEW.
[ChangeLog][CMake] Building Qt as shared libraries now requires
CMake version 3.16 or later. Building user projects with CMake using
that Qt installation also requires a CMake version of 3.16 or later.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I77d2829370f1dfc90b4071bebc8a3ade654e59e6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Quote the paths after "-L".
Get MSVC’s implicit link directories from $ENV{LIB}.
Fix some issues cause by Inconsistent case.
Amends 2c49f85380
Fixes: QTBUG-95198
Pick-to: 6.2 6.1
Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove copying of json files in non-prefix builds.
Previously, this was done to mimic the directory layout of prefix
builds in a non-prefix build, but the extra complexity is not worth
it.
Keeping the files in the build directories of each repo in a
non-prefix build should be good enough.
As a result, we don't need to distinguish which file path should be
passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the
BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3
different paths.
Move the code that handles installation closer together.
Rename the internal COPY_OVER_INSTALL option to
___QT_INTERNAL_NO_INSTALL.
We might want to expose it as a public option later, but it depends on
whether we will disable default installation for user projects.
Remove assignment of some properties that are not used anymore.
Amends c431e2d33c
Pick-to: 6.2
Task-number: QTBUG-94942
Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
All internal libraries, plugins, object libraries (resources, plugin
initializers) need to be built with bitcode flags when targeting iOS.
Internal here means all libraries added by qt_internal_add_X
functions or associated with internal libraries.
We didn't do that for plugin initializers, which were added not too
long ago.
Extract the logic that links to Qt::PlatformModuleInternal into a
separate function to be used for object libraries.
Use it for resources and plugin initializers. It will also be used
in qtdeclarative for qml plugin initializers.
Pick-to: 6.2
Task-number: QTBUG-95208
Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Both the compiler and linker -fapplication-extension flag should only
be applied when building Qt's libraries (not executables).
It's up to the user project whether their code will be restricted with
application-extension-only APIs.
In qmake that can be achieved by adding to the qmake project
CONFIG += app_extension_api_only
In CMake it can be achieved by either adding the compiler and link flags
in the project directly (using target_X_options) or by setting the
appropriate setting in the Xcode project when using the Xcode
generator.
Amends e189126f1a
Pick-to: 6.2
Task-number: QTBUG-95199
Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We shouldn't force add the bitcode linker flags to user projects.
And we don't link anything when building Qt for iOS itself, we only
archive object files into static libraries.
The final decision whether bitcode should be used is up to the Xcode
project. That is controlled by Xcode's ENABLE_BITCODE option.
Bitcode compile flags are still added when building Qt itself.
Amends a046833176
Pick-to: 6.1 6.2
Task-number: QTBUG-95199
Change-Id: I04c77f659b82269bb8010ea262b2e51f36e9def3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This was the case in Qt 5.15 as well.
The CMake toolchain file that Qt's CI is using is already setting
BUILD_SHARED_LIBS to OFF, but it's better to be explicit like we
are with WebAssembly and iOS.
Pick-to: 6.2
Change-Id: Ief17259c15690a97337e9df451663718601c2a52
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise it will confusingly only list the host arch
Pick-to: 6.2
Change-Id: Ic6d080f1fd9ebfa260ce7c35bd5e5b4ee686f083
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The correct variable to check is WIN32, not WINDOWS.
Amends 85e25d93b3
Pick-to: 6.2
Change-Id: I4570eb5a124bcaa0bd38135dd7c7f48345c40c9d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
For internal modules we should keep the name of the file in file system
consistent with previous Qt versions.
Pick-to: 6.2
Fixes: QTBUG-95077
Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_config_linker_supports() repeated the conditions of all use_*_linker
features, because the features are not evaluated yet when this function
is called, and the function needs to know what linker is used to build Qt.
Move the required tests and features before any
qt_config_linker_supports() call and evaluate the use_*_linker features
early.
Change-Id: I306f032356682a0e82e4d7c4234e5bbc820ab143
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since platform definition directory is used as an interface include
path of the Qt::Platform target, it makes sense to define it for this
target only. Also the definition of cached values that contain
path to platform definition looks redundand.
The definition of QT_PLATFORM_DEFINITION_DIR from command line
doesn't make any sense since build procedure doesn't take it into
account when installing mkspecs and the use if the user-provided
QT_PLATFORM_DEFINITION_DIR value as a Qt::Platform include directory
causes inconsistency in the prefixed builds. INSTALL_MKSPECSDIR
and QT_QMAKE_TARGET_MKSPEC should be used instead.
Change-Id: I3636c57b835cb84511a358a0910cc482c5fbd81e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Repositories have been changed to be free of this warning. We're now
changing the default of QT_WARN_PLUGIN_PUBLIC_KEYWORDS to ON.
Set this variable to OFF to disable the warnings.
Pick-to: 6.2
Change-Id: Ie37a4df1032f5b1e9152d970e8a14c574ed70241
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, if a feature was marked as not to be emitted and there was
no user provided value for that feature, the build system would still
save the user provided value in FEATURE_foo with a value of ON (if the
conditions were met).
After a reconfiguration, the build system would hit the code path that
checks if the user provided a value for the non-emitted feature, and
would then warn about it and reset the feature value to OFF.
This would cause errors when reconfiguring a user project, complaining
that a feature value has changed.
Make sure to not save the user provided value for a non-emitted
feature and to always set its internal feature value to OFF.
Amends c4f5762b20
Pick-to: 6.2
Fixes: QTBUG-94921
Change-Id: I257c7fd795c8a6aeba3348cb72522e4f0b006dc9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Rename various functions and variables to hopefully make the behavior
of feature evaluation clearer.
The previous names like 'set_value' or 'set_cache_value' or 'cache'
were too generic and unclear. One would have to carefully read the
code to understand what was actually set.
Add some doc comments about what FEATURE_foo and QT_FEATURE_foo
represent.
Amends c4f5762b20
Pick-to: 6.2
Task-number: QTBUG-94921
Change-Id: Ie6a7b83a4d54a83976b2706d4af82b39832d79f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If Qt was configured with -static-runtime which implies MultiThreaded
-MT flag, the plugin initializer object libraries were still compiled
with the default -MD flag.
When an application linked to Qt, that caused linking to fail with
mismatched symbol errors between the application symbols and the
plugin initializer object library symbols.
Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin
initializer and resource object libraries, depending on the value of
QT_FEATURE_static_runtime.
We did set the property for resources added by
qt_internal_add_resource, but not for the resource created by
the public qt6_add_resources counterpart.
Pick-to: 6.2
Fixes: QTBUG-95043
Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In a -debug-and-release build, apps were placed under bin/Release
rather than just bin.
Apply the logic we use for tools for apps as well. Rename and move
the common functions into QtTargetHelpers.cmake.
Pick-to: 6.2
Fixes: QTBUG-95028
Change-Id: I5a9082ea50c9238c8fcf0c6dd099708fbc571bf8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Make QT_USE_BUNDLED_ INTERNAL to hide them from GUI like QtCreator's
CMake configurator.
Pick-to: 6.1 6.2
Change-Id: Id9dcee31c69b579bbe38611cabb98e46550b0e89
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In our *AdditionalTargetInfo.cmake we now set above target properties
for shared libs only, not executables.
IMPORTED_IMPLIB is only set for Windows.
IMPORTED_SONAME is only set for non-Windows platforms.
Pick-to: 6.2
Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for
non-prefix debug-and-release builds of Qt.
In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the
Debug configuration. In non-prefix builds we export(EXPORT) targets, and
that also contains the non-existent Debug variants of the tools. In
prefix builds, we install(EXPORT) instead, which only exports what is
built and installed.
Consequently, we now remove the DEBUG-related import information if the
debug variant if the target binary does not exist.
Pick-to: 6.2
Fixes: QTBUG-95027
Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_BUILD_DIR should be used instead of CMAKE_BINARY_DIR as a base
directory for platform definition when building a non-prefixed
build since artifacts are copied to qtbase directory for top-level
build.
Amends 478f5fcde6
Pick-to: 6.1 6.2
Task-number: QTBUG-94973
Change-Id: I5cce16fdc7f760b954222ae67a4b85d4beea7f13
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change the default installation prefix to C:/Qt/Qt-${version} on Windows
and /usr/local/Qt-${version} elsewhere.
This is what's expected by users coming from Qt5, and setting the
installation prefix to "/usr/local" manually is easier than setting the
versioned variant "/usr/local/Qt-6.2.0".
[ChangeLog][Build System] The installation prefix now defaults to
/usr/local/Qt-${version} and C:/Qt/Qt-${version} like it did in Qt 5.
Fixes: QTBUG-91632
Pick-to: 6.2
Change-Id: I8ce57b1b18084c705b194c776e038cc807a6ed5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The following host-related configure options were unsupported since Qt
6.0 and are now completely removed:
-hostprefix
-external-hostbindir
-host*dir (except -hostdatadir)
-android-ndk-host
Pick-to: 6.2
Change-Id: Ib69d90c40ef546f61bf87b1f443eb9d10f7a5a21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Platform definition directory is defined when building qtbase.
Depending on the build type (prefixed/non-prefixed) it should point:
- To the source directory when building prefixed qtbase.
- To the installation directory of the prefixed qtbase when building
consumer projects.
- To the build directory of non-prefixed qtbase when building
non-prefixed qtbase or consumer projects.
TODO: It is desirable to move the logic asssociated with Qt platform
definition to the qt_internal_setup_public_platform_target function.
Pick-to: 6.1 6.2
Fixes: QTBUG-94973
Change-Id: I8530613f9b2029834c66206bbdf02475528a4640
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Our only way to detect whether the user requests an Android build of Qt
was to peek into the CMake toolchain file if it is specified. If the
toolchain file contains a certain magic string, we decide that we're
building for Android.
This approach is fragile and bound to break should the Android toolchain
file's magic string ever change.
Now, we assume an Android build if any of our ANDROID_* cache variables
is set. In that case, we do not peek into the toolchain file.
Pick-to: 6.2
Fixes: QTBUG-94955
Change-Id: Ie2f0ac0963f90f09805e311111bb6912d4325ada
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
This reverts commit 7c62caa355.
Certain toolchain files cannot be read in CMake script mode with CMake
versions >= 3.20.
For example, the vcpkg toolchain file overrides add_executable, and
that fails with CMake 3.20:
CMake Error at D:/dev_tools/vcpkg/scripts/buildsystems/vcpkg.cmake:662 (function):
Built-in flow control command "add_executable" cannot be overridden.
Pick-to: 6.2
Fixes: QTBUG-93627
Change-Id: Ib6e6352dff50b9684dcf81401d138e27e16292c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce two new packages WrapVulkanHeaders and WrapVulkan similar to
the OpenSSL wrapper packages.
WrapVulkanHeaders uses FindVulkan and is marked as found if Vulkan
headers are found (that's the only part the Qt build requires).
The WrapVulkan package is currently not used, but is there for
symmetry.
The Vulkan feature is now disabled by default on QNX, because the
QNX toolchain file in the CI does not set
CMAKE_FIND_ROOT_PATH_MODE-like variables and CMake ends up finding
host Vulkan headers causing the build to break.
Pick-to: 6.2
Fixes: QTBUG-92157
Change-Id: I05309821f866456cd42e7f85bf8b76ba099df656
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Specifying the variables as required variable will show the found
paths in the configure output.
Pick-to: 6.2
Task-number: QTBUG-94355
Change-Id: I985a3585f37b38e25b6be4fae5d42c82e06517de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Ensure that the finalizer approach of
__qt_internal_propagate_object_library considers $<LINK_ONLY:>
libraries when traversing the dependencies of a target.
The issue was discovered when using the Quick.Shapes QML module in a
static build. The module has both a backing library and a plugin.
The backing library has some resource objects associated with it.
When the targets are exported, the plugin INTERFACE_LINK_LIBRARIES
has a $<LINK_ONLY:QuickShapes> dependency.
This ensures that the library will be linked, but depending on which
linking approach in __qt_internal_propagate_object_library is used,
the resources might not be linked to the final executable.
The resources are linked correctly when using the
target_link_libraries approach, but not when using the finalizer or
target_sources approach.
This change fixes the finalizer approach, but the target_sources
approach is still broken.
Amends a1fd4f51ad
Pick-to: 6.2
Change-Id: Ifbb91a17d388c3dc4263e17ec0d3bd5627b57cb4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If user specifies non-existing platform build fails in some non-obvious
place, since qplatfromdefs.h couldn't be found.
Add an explicit error if the defined platform folder doesn't exists in
Qt sources.
Change-Id: Id847d57a6f9cc4f463e697b474b8a669cd041fb8
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>
Restores addition of 'float-divide-by-zero' to undefined sanitizer
flags as well as the custom fuzzer-no-link option.
Pick-to: 6.2
Task-number: QTBUG-87989
Change-Id: Icde1e5d31083ce1b6128ab45b0e9df5ae69736a3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an option that automatically generates an export header for a Qt
module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related
content, so it's not a full replacement of 'global' header files.
Task-number: QTBUG-90492
Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a Qt build that was configured with INSTALL_MKSPECSDIR set to
something different than INSTALL_DATADIR, the qmake property
QT_HOST_DATA was wrong. Consequently, mkspecs could not be loaded,
rendering qmake dysfunctional.
The reason was that we considered every QT_HOST_xxx property to have the
same value as QT_INSTALL_xxx in a non-cross build.
This is not true for QT_HOST_DATA, because users might want to set
INSTALL_DATADIR to "foo" but INSTALL_MKSPECSDIR to "bar/mkspecs".
Move the unused determination of the host data dir to the QtLibraryInfo
lib and handle QT_HOST_DATA specially.
Fixes: QTBUG-94591
Pick-to: 6.2
Change-Id: I2c44cda8405ff1d14391254fcd1d9b1361cb5855
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also remove handling of older versions, because we only support
Visual Studio 2019 currently
Pick-to: 6.2
Change-Id: If66a46d970047fe25582e323df74e0a904ee92da
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Go with Emscripten’s default of not shutting down on
main() exit; this allows for writing main() in such
a way that avoids the exec() workaround.
Existing main() implementations (which do use the exec()
workaround) do not shut down Qt cleanly anyway, so we
gain little by shutting down the Emscripten runtime.
Applications can set this flag if they do want to shut
down on main() exit:
LFAGS += -s EXIT_RUNTIME=1
Change-Id: I52e1cc2bc907d1d2146822713e39b7610db3f95b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
There's a number of upstream bugs that cause false positives;
do not make them errors.
Change-Id: I4151794d8d37177a47a34aef8d83accf4377d44a
Pick-to: 6.1 6.2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make Emscripten generate a global constructor function
("createQtAppInstance()") instead of a global javascript
module object.
This enables more fine-grained control over module
instantiation; previously the module object would be
created when the runtime javascript was evaluated, and
the number of emscripten module/instances was limited
to one per page.
Set EXPORT_NAME to “createQtAppInstance” which avoids
collisions with other non-Qt Emscripten modules on
the same page. A further improvement would be to include
the app name in EXPORT_NAME, but this is not done at
this time.
Update the code in qtloader.js to call the constructor
function instead of working on a global module object.
The qtloader.js API is functional before the wasm and
Emscripten modules have been instantiated; store properties
and forward to the Emscripten module when it's created.
Change-Id: I12c49a5b9a4a932bbc46fcc5e5ecc453fd0fe7f0
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
new syntax rules for EXTRA_EXPORTED_RUNTIME_METHODS valid after 2.0.16
Pick-to: 6.2
Change-Id: Iff33e4c6f3176619fb35ec0994a7cc87b5d937c7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Remove the temprotary 'Private' targets of the iternal modules.
Pick-to: 6.2
Task-number: QTBUG-87775
Change-Id: I9a2c7c8c2f63602476fd935b11dab7a835864537
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Check if link order matters before use the object library finalizer.
Amends 5fb99e3860
Pick-to: 6.2
Change-Id: Ie996bc175ebea36ccda1bb2fe388ae3b7fcde395
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Perform a file name of the config header before adding a '_private'
suffix.
TODO: It makes sense to revisit the use of the CONFIG_MODULE_NAME
variable since the variable is used for different purposes and
mutate with use.
Amends 8aee7c6b29
Pick-to: 6.2
Fixes: QTBUG-94568
Change-Id: Id5aaf8d423ec8b94afffe4641b54dab94b5453fb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The linking logic of object libraries should be reusable outside of the
resource context. This introduces a
__qt_internal_propagate_object_library function that prepares all the
necessary genexes to link and propagate the object library to the
end-point executable.
Rename resource object finalizer API to make the naming more generic
to object libraries of any kind.
Amends 5fb99e3860
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtPriHelpers copies the logic related to the module OUTPUT_NAME to
produce a module identifier. Since the module identifier should be
equal to OUTPUT_NAME it makes sense to reuse the property and
deduplicate logic.
Amends 8aee7c6b29
Pick-to: 6.2
Fixes: QTBUG-94568
Change-Id: I8d9c04273e4cdb1a2e6a3b0db3ddf52e008c0cf7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
GCC 11.1 has a bug [1] in the preprocessor that leads to
-Wsuggest-override warnings being raised in random places, even under
pragmas that are supposed to suppress it. For some reason, NOT using the
integrated preprocessor fixes it, so add that flag as a workaround.
Also, GCC 11 introduces a family of warnings for C++20's deprecations of
mixed enum arithmetic, which we use all over the place. Avoid a hard
error for those warnings.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
Change-Id: I3b2aefa385f191f207e7eb876bc1ed0b18fb342b
Pick-to: 6.1 6.2
Task-number: QTBUG-93360
Task-number: QTBUG-94059
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The optional components arguments were not handled before which
caused the recorded package information for static builds to be
incorrect, it only recorded the package name without the component.
Remove REQUIRED_COMPONENTS TODO, there is no such find_package option,
it's already handled by the regular COMPONENTS code path.
Amends 07b6d3367d
Pick-to: 6.1 6.2
Fixes: QTBUG-94501
Change-Id: Ib48a7befcb70e20c3f21315897d51d3064b48134
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dominik Holland <dominik.holland@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set the correct value to the _qt_config_module_name property at the
internal module creating step instead of appending _private suffix when
generating .pri files.
Amends 425ff34aa1
Pick-to: 6.2
Fixes: QTBUG-94568
Change-Id: I6fa8089358bc638668e313c98c3aee680bf7ec2a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for qtdeclarative so we can filter out which object library
should go into which export set, because qt_internal_add_qml_module
can create both a backing library export set and a plugin export set.
The plugin initializer object lib should go to the plugin export set.
Pick-to: 6.2
Task-number: QTBUG-92933
Change-Id: I0fce131eff75a0b3090ac0fbb2a12ecfcba5e38d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is needed for a change in qtdeclarative to allow building the
Q_IMPORT_PLUGIN-containing object library initializer of a qml plugin.
Show an error if the qml plugin has no class name, it's needed for
plugin initialization so it's mandatory to have a class name.
Show an error if a class name is not found when computing the import
macro for a plugin (both for a regular qt plugin and a qml plugin).
When querying for the class name of a target, query both a Qt6::
prefixed target as well as a non-prefixed one, with the Qt one
taking precedence.
This is to allow querying the class name of user project created qml
plugins.
Currently regular qt user plugins don't use the object library
initializer approach. This will likely be revisited in the future.
Pick-to: 6.2
Task-number: QTBUG-92933
Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We didn't do it in Qt 5 times and it was accidentally done for Qt 6.
There's no reason to generate them, the .pri files are only meant to
be used for regular plugins so a project can do QTPLUGINS += foo.
That mechanism is not needed for qml plugins which use
qmlimportscanner instead.
Furthermore the pri contents didn't contain a class name, so they
couldn't be used anyway.
Pick-to: 6.2
Change-Id: I6299fda21ece0f693a817ab558b45aa46b97e5ee
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Only depend on the ${project}_src and ${project}_tools targets.
This might exclude some non-obivous target dependencies, but we can
adjust that if needed.
This reduces the build.ninja file of qtbase + qtsvg form 341MB
to 41MB when configuring with tests and examples, as well as reduces
the processing time of calling ninja.
Amends d97fd7af2b
Pick-to: 6.2
Change-Id: I2860d8ae89728f33f6b73fede1335cd6d6290f78
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
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>
Automatically set compilers based on old mkspec style target
Pick-to: 6.2
Change-Id: I80404376964a85c6b519657c054d008da47aed91
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change allows temporarily removing the EXTERNAL_BUILD option in
a qt repo examples project to check how the examples behave in a
non-external project build, without forcing the developer to use a
prefix build.
Useful to compare behavior until we've ported over prefix builds to
use EXTERNAL_BUILD.
Amends d97fd7af2b
Change-Id: I29b834bb5f00e1e93966caae6f816faedba76b76
Reviewed-by: Craig Scott <craig.scott@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>
Removing flags based on REGEX may include spaces, so flags might be
glued. Replace flags with spaces to keep at least one space for
the described case.
Pick-to: 6.2 6.1
Fixes: QTBUG-94400
Change-Id: Ice268da36174ef5cf4398d2aee8fcd4731336316
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add 'Private' suffix to the internal module names in the mappings of
the qmake files for modules of the qtdeclarative repo.
Change-Id: I1592ebad0f0db553322ea766561b1b8c3fd38aea
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
'ld' only capable to resolve circular dependencies by wrapping the
suspected static libraries and objects using --start/end-group
arguments. We want to detect if linker is 'ld' at configure time to
decide how to link the resource objects if finalizers are not enabled.
The qt_config_compile_test function is extended with an extra argument
since it's required to pass custom cmake flags to the ld-related test.
Pick-to: 6.2
Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This means calling 'ninja apk' in a Qt build with examples configured
will build all example apks, regardless of whether the examples are
built as external projects or in-tree.
Fixes: QTBUG-94264
Change-Id: I5c7af0354858898a2e154a6d54fb025e4d81ff80
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qmake had support for building with clang-cl as the win32-clang-msvc mkspec.
Task-number: QTBUG-89642
Task-number: QTBUG-88081
Change-Id: I0709c289f90fedb121620d1e67ef841602219816
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now,
and we can remove QtCompatibilityHelpers.cmake altogether.
Change-Id: I4d8104246e96a4514d5651c104607d651d208d95
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add FindWrapSystemMd4c.cmake so that the old md4c target can be used
as well as the new one and set WrapSystemMd4c_FOUND.
Link to the imported target WrapSystemMd4c::WrapSystemMd4c if the
system library is used.
Add qt_find_package line to find the package in configure.cmake.
Fix the condition for enabling system-textmarkdownreader, it includes
testing for textmarkdownreader because even if the code would compile
correctly without it, it looks strange when the output says
"textmarkdownreader no" and under "using system libmd4c yes" even if
libmd4c is not used.
Use system include when system-markdownreader is enabled.
Add library mapping for libmd4c.
Change-Id: Id5d5b13d6691a8c1cdf627238887977c847c1e67
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move collected resource objects to the beginning of the linker line to
prevent order-related issues.
Fixes: QTBUG-92250
Change-Id: Ia046f2820feb693bfadc2b60e07fa001638d4d7b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qtattributionsscanner is now found in libexec.
Task-number: QTBUG-88791
Change-Id: Ie704663012be92b0c223d9d57210ec1874abff0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For Apple's frameworks it's possible to include header files using the
following assumption:
If the framework name is "MyFramework" then
'#include <MyFramework/frameworkheader.h>' will work without specifying
the include path explicitly. This is broken for internal modules since
they use the framework name with the 'Private' suffix.
This uses the module name instead of the target name as a framework
name.
Amends edbe0eb335
Task-number: QTBUG-87775
Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Resource objects might be linked to plugins. Since some plugins may
be present in LINK_LIBRARIES as the complex genexes, need to collect
them explicitly and iterate over plugin targets to find resource object
libraries that need to be exposed to end-point target executable.
Amends a1fd4f51ad
Change-Id: Icd85f54f7bf9d1b7e3382caa5d9aa62449b6adb8
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before, it would erroneously look for them in the source directory.
Change-Id: I6dcd3ccde3e57dba84639da2cd354c51e8a92459
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd),
cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we
use this Qt to build a qmake project, compilation will fail due to
missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an
object file instead of a library.
Library names in qt_module.pri and qt_lib_*_private.pri are also
missing "-l" prefix.
This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals
"-l". But on MSVC, it is an empty string. So we should pass
"-DLINK_LIBRARY_FLAG=-l" for MSVC.
Also add "-L/path/to/library" if the library path is not in default
linker search directories. This will write un-relocatable paths to prl
files only when using 3rdparty libraries to build Qt statically. Usually
it's not a problem.
In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on
MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid
generator expression. This means no include dir will be written to
qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>"
when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty.
Pick-to: 6.1
Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and make it consistent with that of qt_internal_add_module.
Make EXTRA_CMAKE_FILES a multi value keyword.
Do not add include statements for every file in EXTRA_CMAKE_FILES.
Add the EXTRA_CMAKE_INCLUDES argument to specify includes.
This enables us to specify EXTRA_CMAKE_FILE that are not included.
Change-Id: I1a3667473b94ee44363b554ab9e6c380e5c11389
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building Linux packages, we pass OpenGL_GL_PREFERENCE=LEGACY when
building qtbase. This is done to link against legacy OpenGL libs.
When building non-qtbase repos, we also need to set this variable to the
same value we have in qtbase.
Pick-to: 6.1
Task-number: QTBUG-89754
Fixes: QTBUG-94040
Change-Id: I567b629d245025d2b1544b91cfc265a9c921725f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid getting the LINK_LIBRARY property of the interface libraries
when calling a resource object finalizer.
Amends a1fd4f51ad
Change-Id: I19d625a927c66994902f5c89e6c82183c94af91e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Versioned tool targets are always promoted to global targets.
Versionless ones were not promoted to global targets.
This was an oversight which caused issues with conditions like
if(TARGET Qt::Tool) in top-level builds.
Fixes: QTBUG-93839
Change-Id: I5176899b5d0d80bfd0b350bc9c4b3fa5b53c0777
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>
In the future it might be useful to print the config summary entries
of a Qt module configure.cmake file even if the associated module
is not built and thus qt_feature_module_begin is not called.
The repo src/CMakeLists.txt could then use a combination of
qt_feature_evaluate_features and a conditional
qt_feature_record_summary_entries to ensure the that summary entries
are still shown.
Change-Id: I124efc82163ddae48d9e72c70a677ec4c6588fac
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since the information about framework is performed in multiple places
it's quite hard to control its consistency. This moves the obtaining
of framework related information to the common function and adjusts
the use of the information across the repo.
Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the previous implementation of the resource object finalizer, we
used the name of the resource object library without namespaces when
recording it in the resource libraries list. This causes an issue when
we or users export resource targets.
This approach marks resource object libraries with the exporting
property instead of collecting resource targets when creating them.
Amends 19e789bace
Change-Id: I8596815921f2c681ddd78d9b2e9a4e1cafe5000b
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
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>
Only use plugin finalizer mode if qt_finalize_target is called at the
end of the user project (which we can't really check, the user has to
ensure that) or when qt_finalize_target is automatically defer-called
by CMake 3.19+ (which is done by qt_add_executable).
This removes the previous behavior of using the finalizer mode if
qt_import_plugins is called. Instead the old regular mode is used
if the above preconditions are not met.
The removed behavior had ordering issues if qt_import_plugins was called
before target_link_libraries. The dependency walking would be done
before Qt dependencies were added and thus no plugins would be
linked.
Amends 6fcc272ac9
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Task-number: QTBUG-94030
Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
fix debugging demangler
Emscripten apparently does not like the quotes in the compiler argument
and remove array syntax
Change-Id: I66652f6bdc5872faf540a877ca01bf75dde47bbb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Examples are intended to show how to build against an installed Qt.
Building them as part of the main build means the way the Qt targets
are defined and created are not representative of an end user's build.
By building them as separate projects using ExternalProject, we can
more closely replicate the intended audience's environment. This
should allow us to catch more problems earlier.
Having examples built as part of the main build also creates problems
with some static builds where a tool built by the main build is needed
during configure time. This happens with other repos like qtdeclarative
but not (currently) with qtbase. Converting the examples in qtbase to
be built using ExternalProject is intended as a demonstrator for how
other repos can do similar. Until other repos are converted, they will
continue to work as they did before, with examples as part of the main
build for non-static builds only.
The new build-externally behavior is only supported for non-prefix
builds with this change. Prefix builds will continue to use the old
non-external method. Support for building examples externally in
prefix builds will be a separate change.
Task-number: QTBUG-90820
Fixes: QTBUG-91068
Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It was copy-pasted (presumably from plugin handling code)
when initially introduced but was never used.
Change-Id: I571738b9f5269ca038f5931a773aa5c2c66aafbc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Internally it uses a new _qt_internal_add_library function (similar
how we have qt_add_executable and _qt_internal_add_executable) as well
as finalizer code line the executable case.
_qt_internal_add_library forwards arguments to add_library with some
Qt specific adjustments to the selected default target type (based on
whether Qt is configured as static or shared).
The new _qt_internal_add_library is now used in qt_add_plugin as well
as some internal library creating functions like
qt_internal_add_module.
This reduces some duplication of file name adjustments across
functions and creates a central point for creation of Qt-like
libraries (for some definition of Qt-like).
Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Since we add 3rdparty libraries to the set of the Qt modules, they are
treated as the Qt modules by the depenedcy helper as well. So give them
_qt_module_interface_name to fix dependency helper.
Amends 425ff34aa1
Change-Id: I5898c1c90156de1878aeeef5a0924349b44c50fa
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We need to export the Private targets of the internal modules to keep
compatibility with existing internal module users across repositories.
Amends 425ff34aa1
Fixes: QTBUG-93943
Change-Id: I10234cec1eb618b69d041f80fbe29620a4e307b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When dealing with a universal build of Qt, we would end up
using the QT_ARCH as the architecture for user projects,
but this architecture is always the primary one that Qt
was configured with.
Instead of relying on QT_ARCH, we start writing QT_ARCHS
(plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES,
and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS.
We then resolve the active arch using uname -m, matching
what CMake does.
We still feed all the available architectures to the
Makefile or Xcode project, so that the user can build
for any of the available architectures without needing
a reconfigure.
Fixes: QTBUG-93760
Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After discussion we decided to opt-out the UNICODE definintion
behavior. To disable UNICODE in user projects the
qt6_disable_unicode_defines function could be used.
Amends 5b64e5950c
[ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on
WIN32 platforms by default for all cmake projects to reflect the
qmake behavior. Use qt6_disable_unicode_defines function to disable
the default unicode definitions.
Pick-to: 6.1
Fixes: QTBUG-93895
Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HEADER_MODULEs use the INTERFACE visibility to link libraries. This
causes a transitional propagating of the Qt-internal compile definitions
and options to the user targets.
This commit avoids an implicit adding of the Qt::PlatformModuleInternal
library to the HEADER_MODULEs and stops propagation of the Qt-internal
compile definitions and options. If module wants the transitional
propagation of some properties, this needs to be done explicitly.
Amends 8b7894cb63
Pick-to: 6.1
Fixes: QTBUG-89951
Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cmake, targets are used as an entity for modules. This causes a
number of problems when we want to manipulate a module as a separate
entity with properties associated with it.
The _qt_internal_module_interface_name target property is introduced to
represent the module entity. All modules write a name to this property,
which will subsequently expand into the module name matched with
the module name in qmake.
The 'qt_internal_module_info' function is responsible for providing the
correct values for the module properties used when working with a module
target.
Unlike qmake, for internal modules in cmake it is expected that the
Private suffix will be specified explicitly. In case the user wants to
have a different module name, an additional argument
MODULE_INTERFACE_NAME of the qt_internal_add_module function is
introduced.
This also changes the way how target dependencies are collected and
resolved. Since the 'Private' suffix no longer means an unique
identifier of the module 'Private' part, we look for the both Private
and non-Private package names when resolving dependencies.
TODO: This change doesn't affect the existing internal modules, so to
keep compatibility with the existing code the existing internal modules
create 'Private' aliases. The code that provides backward compatibility
must be removed once all internal modules will get the proper names.
Taks-number: QTBUG-87775
Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the concept of repository target sets, which is a named set of
targets within a Qt module repository.
In a Qt repository, a repo target set 'qtfoo' can be defined in the
top-level project file with
qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz)
The DEPENDS argument specifies Qt components that need to be
find_package'd when building the targets that belong to qtfoo.
In subdirectory project files, use
qt_internal_include_in_repo_target_set(qtfoo) to mark the file as
belonging to the repo target set.
To build and install a single repo target set, specify
QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt
repository.
Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow linking all plugin initializer object libraries directly
into the final target (executable or shared library).
The finalizer mode is triggered when the project adds a call
to qt_import_plugins, as well when the project has an explicit
call to qt_finalize_executable or when it is defer called by
CMake 3.19+.
Otherwise the old non-finalizer mode is used, where each plugin
initializer object library is propagated via the usage
requirements of its associated module.
A user can explicitly opt in or out of the new mode by calling
qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE)
The implementation, at configure time, recursively collects all
dependencies of the target to extract a list of used Qt modules.
From each module we extract its list of associated plugins and
their genex conditions. These genexes are used to conditionally
link the plugins and the initializers.
Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the
property even on INTERFACE libraries with lower CMake versions.
QT_PLUGINS is kept for backwards compatibility with projects already
using it, but should be removed in Qt 7.
The upside of the finalizer mode is that it avoids creating link
cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to
duplicate the library on the link line, slowing down link time as well
as possibly breaking link order dependencies.
The downside is that finalizer mode can't cope with generator
expressions at the moment. So if a Qt module target is wrapped in a
generator expression, it's plugins will not be detected and thus
linked.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead of compiling the plugin initializers as part of a user
project, pre-compile them as object libraries while building Qt.
The installed object libraries can then be used with
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
so that they are linked into the final executable or shared library
via qt module usage requirement propagation.
This reduces the build times of user projects.
The link line placement of the object files should be correct for all
linux-y linkers because the only dependency for the object files is
Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that
from empirical observations.
As a consequence of the recent change not to link plugin initialization
object files into static libraries, as well not having to compile the
files in user projects, we can get rid of the
_qt_internal_disable_static_default_plugins calls in various places.
A side note.
Consider a user static library (L) that links to a Qt static library
(Gui) which provides plugins (platform plugins).
If there is an executable (E) that links to (L), with no direct
dependency to any other Qt module and the intention is that the
executable will automatically get the platform plugin linked,
then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage
requirements are propagated successfully.
This is a limitation of using
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
which will propagate object files across static libraries only if
qt_module is linked publicly.
One could try to use
target_link_libraries(qt_module
INTERFACE $<TARGET_OBJECTS:plugin_init>)
which preserves the linker arguments across static libs even if
qt_module is linked privately, but unfortunately CMake will lose
dependency information on Core, which means the object files might be
placed in the wrong place on the link line.
As far as I know this is a limitation of CMake that can't be worked
around at the moment.
Note this behavior was present before this change as well.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is to allow other repos like qtdeclarative to more easily pass
through supported arguments to qt_internal_add_module() from their own
functions.
Task-number: QTBUG-88763
Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Q_IMPORT_PLUGIN generates a global static symbol that initializes a
plugin. If this symbol is added to a static library and the library
is then linked to an executable, the linker decides that the symbol is
unused (because nothing references it) and discards it.
This means there's no point to compile the Q_IMPORT_PLUGIN containing
files into static libraries.
Change the generator expression we use for plugin propagation via
associated modules to not compile and link the plugin initialization
object file into a static library.
Pick-to: 6.1
Task-number: QTBUG-80863
Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it
is set to ON. Users can set this option to OFF to disable versioned
hard link.
Pick-to: 6.1
Fixes: QTBUG-93636
Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES
Pick-to: 6.1
Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
Use paths configured with QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to search also for the tool packages.
Task-number: QTBUG-93565
Pick-to: 6.1
Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sometimes projects don't follow the standard directory layout, so they
end up copy-pasting the guts of qt_build_repo and adapting that.
Split the macro into smaller ones so it's easier to reuse.
Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
list(PREPEND) command was added in CMake 3.15+, but so far we claim
support for CMake 3.14 in user projects.
Use set command instead.
This is not the only place where we use list PREPEND in public API,
but it's the first immediate issue that comes up when using CMake
3.14.
Amends 963017f588
Pick-to: 6.1
Change-Id: I7ba4507fc7da2dc550317848751502b8b46c298c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We want standalone tests added by qt_internal_add_test to be built as
universal executables, so we can build them on an intel machine and
run them on an ARM machine.
But CMake build tests will be built on the final machine that runs the
tests and it might lack a universal SDK. That's why they should be
built only targeting the architecture of the machine they're running
on.
Change the generated qt.tooclhain.cmake file to allow opting in or out
of building projects with the same architectures as Qt was configured
with.
Now standalone tests will be multi-arch, but CMake build tests will be
single-arch.
Amends e379147f95
Task-number: QTBUG-85447
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The -developer-build had not the desired effect anymore.
That argument must not be hidden from the feature logic.
This amends commit d5c3e1336b.
Change-Id: I96562ea2df43ba7de002e705f28c7cc7edb4a589
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Let -developer-build, -cmake-file-api set up the CMake File API query,
so that the build can be loaded directly into IDE's like Qt Creator.
[ChangeLog][Build System] configure -developer-build now sets up
the CMake File API query, so that a build can be loaded without
reconfiguration into Qt Creator and other IDE's. Pass
-developer-build -no-cmake-file-api to configure to disable this.
Fixes: QTBUG-89487
Change-Id: I69199b8f96da02e42e5610aa6f49881c1582f7da
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
BrotliCommon is a dependency of BrotliDec and BrotliEnc.
amends 5d2da76c1e
Pick-to: 6.1
Change-Id: I7741d417e95737f8caacd01962985a27dbb7514c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing this configure argument will generate a JSON file that contains
information about configure options and features.
This file is used by Qt's conan recipes.
Fixes: QTBUG-92082
Change-Id: I2057ec8cbdb0a1ea198d7eeacb45f65bfa862d8a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
file(REAL_PATH) was introduced in CMake 3.19.
Use get_file_name_component(... REALPATH) instead that is available in
older CMake versions.
This amends commit b226e99c71.
Pick-to: 6.1
Change-Id: Ibb28ef757228e1a1176ff70c3ec57b7ca751a636
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The libraries already contain the ABI suffix, and the .prl files should
too. This is a requirement for ABI-stitching of Qt Android builds.
Fixes: QTBUG-90023
Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clarify that OUT_FILE is not the final .prl anymore and where we get the
path of the final .prl from.
Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call
add_custom_command/add_custom_target. This is necessary to setup
the necessary environment for the tool to run correctly. This approach
is weak according to CMake documentation:
"If more than one COMMAND is specified they will be executed in
order, but not necessarily composed into a stateful shell or
batch script."
This change introduces the _qt_internal_wrap_tool_command function
that uses a wrapping script that setups necessary environment for
the tool and runs it in a single shell.
The script is generated by the _qt_generate_tool_command_wrapper
function.
Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt_internal_module_info function suppose to provide the information
only about the Qt modules. Avoid using it for the tool and extra
package dependencies, since some targets do not always exist, when
function is called.
Add the qt_internal_qtfy_target function to make the prefixed target
names.
Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
... and configuring another repo using qt-configure-module.
It's possible to configure a top-level Qt with a subset of repos and
then afterwards configure additional repos with qt-configure-module.
We didn't define QT_REPO_DEPENDENCIES in that case, which caused all
plugin config files to be loaded on reconfiguration, thus causing
duplicate target errors.
Move the QT_SUPERBUILD check to be done every time in
QtBuildInternals.cmake rather than when configuring qtbase/qt5.
Amends 98e8180e56
Pick-to: 6.1
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Fixes: QTBUG-92578
Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Packagers usually build Qt per repo, but the documentation must be built
from the full Qt source archive to ensure that inter-repo links are set
up correctly. When building the documentation, it's desirable to avoid
building tools and re-use to tools of an existing Qt build.
One now can do a documentation-only build by configuring Qt like this:
cmake /path/to/Qt/source -GNinja \
-DQT_HOST_PATH=/path/to/Qt/installation
and build the documentation with
ninja docs
To avoid building tools, this patch removes the DEPENDS arguments from
some add_custom_target calls in QtDocsHelpers.cmake and makes another
one conditional. The removed dependencies are added at the end of
qt_internal_add_docs. Adding of tool dependencies is not done if
QT_HOST_PATH is set.
Fixes: QTBUG-88441
Change-Id: I3b7a908e22d252d2edcdc1dd522a78b8ad6c487e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's necessary to have versioned alias of the Platform target to use
versioned target in the installable cmake files.
Pick-to: 6.1
Change-Id: I79286e1c0642068bdfa5d24c1087ee0c39e48f1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When configuring a Qt module with qt-configure-module, we want to use
the same CMake generator that was used for building qtbase.
That generator is encoded in qt-cmake-private. But qt-configure-module
overrides the generator after trying to detect what generator should be
used. That auto-detection is only useful for qtbase-builds and top-level
builds. Turn it off for repo builds other than qtbase.
Pick-to: 6.1
Fixes: QTBUG-91405
Change-Id: I07efb4afb51ba69d2f5467d272118fa51637ab54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's important for conan CI builds where the correct installation
location of Qt should be used when configuring standalone tests.
Task-number: QTBUG-93037
Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously, in a top-level build we always generated the final prl
file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After
each repo was processed by QtPostProcess.cmake, we installed the prl
files found in PROJECT_BINARY_DIR.
For qtquickcontrols2 this meant that qml plugin prl files were placed
under qtbase/qml, but we tried installing the prl files from
qtquickcontrols2/qml, which didn't have any prl files.
In a static Qt build, qmake's qt.prf calls qmlimportscanner to
identify which plugins should be linked to the executable. This worked
fine because the plugin .pri files were installed correctly.
None of the qml plugin library dependencies were linked in though.
This is supposed to happen in qmake's C++ code where it tries to
find the associated prl file of a linked library in order to extract
all its dependencies. Because no prl file was found, linking failed
with multiple undefined symbols.
Fix this by installing the prl files from QT_BUILD_DIR rather than
PROJECT_BINARY_DIR.
Note that this will create multiple install rules for certain files,
but it's harmless. An example is imageformats.
We process qtbase plugins, see qjpeg, issue an install rule from under
the qtbase/plugins/imageformats folder. We then process
qtimageformats plugins, see webp, issue another install rule from
under qtbase/plugins/imageformats.
The first install rule will install both qjpeg and qwebp, the second
install rule will merely say all plugins are up-to-date.
Pick-to: 6.1 6.0
Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2
Fixes: QTBUG-93021
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Passing Android-related variables to the initial CMake call would have
no effect if no (or an empty) value of CMAKE_TOOLCHAIN_FILE was
specified. To alleviate user confusion, yield an error if an Android
build was apparantly requested, but the toolchain file is missing.
Change-Id: I28ec94eabe436d4b9b410b48c7cad1b48d3e1bec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before, we relied on the deprecated "ndk-bundle" subdirectory being
present in the SDK root. Now, we choose the NDK with the latest version
in the SDK's ndk subdirectory.
Pick-to: 6.1
Fixes: QTBUG-87579
Change-Id: I37a9e03184f4518b4074d55375af08209591de94
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When ANDROID_NDK_ROOT is explicitly set by the user, there's no point in
detecting the NDK. The detection had no effect, because the already set
ANDROID_NDK_ROOT variable would not be overwritten by our set call.
Fix the condition of the check: There is no CMAKE_ANDROID_NDK_ROOT
variable.
Pick-to: 6.1
Change-Id: I8f0d4f2a1a67445f67a79c7d2d0932099828b05e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's needed in qtconnectivity, but currently the
qt_disable_apple_app_extension_api_only function is defined in
QtInternalTargets.cmake which is loaded only in qtbase.
Move the function to cmake/QtTargetHelpers.cmake.
Amends e189126f1a
Pick-to: 6.1
Change-Id: Ia2470e48a91385239394368780f5bbb223000113
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross compiling from a case sensitive file system, casing
matters, and mingw headers and import libraries consistently
use lowercase.
This was uncovered by d385158d5213ef568b7629e2aa4a818016bbffac;
prior to that, the schannel TLS plugin didn't end up built (at
least when cross compiling).
Fix other similar cases that can be found by grepping the repo.
Change-Id: Ia696e17b7aaa979d7b7f5b0801383f338a8b585b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Currently in order to compile a Qt6 test standalone one needs to use
the qt-cmake-standalone-test script which will load the
Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project
with the current test source directory to create a complete CMake project.
This commit will allow a test to have these lines at top:
cmake_minimum_required(VERSION 3.16)
if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
project(a_qt_test LANGUAGES C CXX ASM)
find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST)
endif()
and be standalone and work with any IDE capable of loading CMake projects.
Fixes: QTCREATORBUG-25389
Pick-to: 6.1
Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard
build plugins associated with Qt modules from other repositories
(qtsvg's QSvgPlugin associated to qtbase's QtGui).
When configuring in-tree tests in the same build folder as the
repository, the test executables would not automatically link to these
plugins.
Fix this by recording the existence of such plugins in a separate
property of the associated Qt module and only link them when both the
test executable and plugin are from the same project (their
PROJECT_NAME coincides).
This is in addition to linking the plugins associated with the
module where both are built in the same repository.
The logic is a bit tricky and ensures that plugins are not
accidentally initialized twice, so that in-tree tests work for both
top-level and per-repo builds.
As a drive-by, added a TODO explaining why in-tree tests that need to
link to static QML plugins won't work (somewhat unrelated to this
change).
Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b
Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2
Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add SOLARIS cmake platform definition.
Add settings for QT_DEFAULT_MKSPEC so that qplatformdefs.h can be found.
Solaris has its gssapi symbols in libgss.
Solaris supports @ORIGIN.
Solaris ld does not support --dynamic-list needed for reduce relocations.
Make solaris fail the reduce relocation test.
getauxval is specific to GNU libc and some other libc implementations on
Linux but sys/auxv.h is not. The bootstrap uses sys/aux.h as the only
indication for getauxval. This breaks builds on Solaris, so only make
sys/auxv.h an indicator for getauxval on linux or glibc based systems.
Solaris uses X11 so add it to the X11_SUPPORTED list.
Solaris network libraries for sockets etc are in socket and nsl.
ifreq does not have a member ifr_ifindex on Solaris, it uses
ifr_index. Add test to check if ifr_index is a member of ifreq.
The first struct in the in_addr union on solaris is defined as four
uint8_t, therefore four arguments are needed for its initializer list.
Change-Id: Ieed4c1bbac8559a7ae1db9c4e1e91f609f150270
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The change introduced in 98e8180e56
fixes reconfiguration issues for repositories that provide plugins
associated with modules from a different repository
(QSvgPlugin -> QtGui -> qtbase).
It does so by only loading the public Plugin CMake packages of
dependent repositories.
For executables / tests that are built as part of the current
repository, plugins are linked via a different simplified mechanism in
qt_add_internal_plugin and qt_internal_add_plugin in order to prevent
exporting link cycles between plugins and Qt modules.
This works for the majority of in-tree tests, but unfortunately breaks
static standalone tests.
For example in qtbase neither mechanism will link plugins to the
standalone tests:
- qtbase has no repo dependencies, so the first mechanism (loading of
public plugin packages) is skipped because we assume we are merely
reconfiguring the main build of qtbase and we don't want to
accidentally create duplicate plugin targets
- because a standalone test configuration does not call
qt_internal_add_plugin, no association is done between qt plugin
and module and thus all tests (qt_internal_add_test ->
qt_internal_add_executable) don't get the simplified plugin
linking
Fix this by allowing loading of the public CMake plugin packages when
doing standalone tests. It should be safe to do so because we don't
build any plugins in this case, only tests.
Amends 98e8180e56
Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In commit 013abe3206, I add
_CRT_SECURE_NO_WARNINGS definition for all Qt internal module targets,
to suppress MSVC warnings like:
warning C4996: 'strncpy': This function or variable may be unsafe.
However, when compiling some internal tools, such as qmake and qdoc,
such warnings also exist. To suppress this kind of warning entirely,
_CRT_SECURE_NO_WARNINGS definition should be added for all Qt internal
targets when using MSVC compiler.
Pick-to: 6.1
Change-Id: I9c37b20672f9d0f470e3e9ea847e5221f43bfc04
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Currently, FindWrapBrotli.cmake depends on vcpkg or PkgConfig. But for
users who build Brotli by themselves and don't have vcpkg or PkgConfig,
the Brotli cannot be found.
As a reference, I use following CMake commands to build Brotli:
cmake path/to/Brotli/source -G"Ninja Multi-Config"
-DCMAKE_CONFIGURATION_TYPES=Release;Debug -DCMAKE_CROSS_CONFIGS=all
-DCMAKE_DEFAULT_CONFIGS=all -DCMAKE_DEBUG_POSTFIX=d
-DCMAKE_INSTALL_PREFIX=path/to/install
Pick-to: 6.1
Change-Id: I2fa8d3293dd55ebc18937e13fac40d144ca4c1e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On the CI system, we build qtbase with CMAKE_INSTALL_PREFIX set to a
path without a drive letter to support DESTDIR when installing.
Other Qt modules are built without CMAKE_INSTALL_PREFIX set. The
Qt6BuildInternals package provides a default value.
Since commit e6527e2f73 this default
prefix is calculated from the current installation location. This
default prefix however has a drive letter, breaking DESTDIR support.
Broken DESTDIR support in this case means for Android that file(INSTALL)
can properly install but stripping will silently fail.
We now compare the "real path" of the original prefix from qtbase and
the calculated prefix. When they're equal, we use the original
CMAKE_INSTALL_PREFIX.
Fixes: QTBUG-92890
Change-Id: I96fb0655e02c5c695722b7e01a32e209cbdea4cc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 15b26935fca4ab14298abdcc70b3cb15b6cca195)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
Xcode allows building a project targeting either the device or
simulator sysroot in one single build dir, but for the sysroot
switching to work there should be no linker or compiler flags
referencing absolute paths of a specific sysroot.
During CMake configuration of a project targeting iOS, all found
system libraries will be within one single sysroot, either the device
one or the simulator one, whichever one was passed to
CMAKE_OSX_SYSROOT. CMake will then generate the Xcode project
and pass those absolute paths, which makes sysroot switching within
Xcode not work.
To avoid that, the CMake documentation recommends passing linker and
framework flags of the form '-lfoo' and '-framework bar' instead of
absolute paths. Xcode then takes care of setting the correct framework
search path.
Zlib is one of the libraries found in the iOS sysroot and thus passed
as absolute path.
To avoid that, create a new FindWrapZLIB find script. The target it
creates will pass the absolute path to the library on non Apple
platforms and an -lz linker flag on Apple platforms (macOS and iOS).
To avoid issues with target global promotion when system PNG package
is found, ensure that a found ZLIB::ZLIB target is promoted to global
manually in src/gui/configure.cmake.
Pick-to: 6.1
Change-Id: I8bd8649be4f680a331ad51925f27cb9d13ac5e5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The directory-level targets missed the first level of sub-targets.
E.g. `qtbase_qmake` did not have a dependency to `qmake`.
Fix qt_build_internals_get_repo_targets to first grab all targets of the
subdirectory and then recurse.
Pick-to: 6.1 6.0
Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
With CMake 3.20.1 AUTOMOC can crash or hang on Windows when used with
a Qt installation that supports moc depfiles due to missing
multi-threaded locking.
Warn and advise to use a different CMake version instead.
Change-Id: I78d2269c48dfc2541bebcd6ab23aaa5595012149
Pick-to: 6.1 6.0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need the metatypes for anything directly or indirectly exposed to
QML. Switching this on has no runtime overhead. For interface libraries
we cannot generate any metatypes, though.
Change-Id: I7b7f85bb4e16c28d00383c5c88b0f1c172c8d193
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Homebrew introduced a new default prefix for Apple Silicon machines,
so that both arm64 and x86_64 packages can be co-installed on a single
system.
The intel packages are installed into /usr/local and the arm64
packages are installed into /opt/homebrew.
For Qt building purposes, we don't want to find packages in any of
homebrew's prefixes unless explicitly requested by the user
Currently our arm64 macOS CI config does pick up system libs under new
prefix.
Remove the new path from the system prefixes.
Amends f3c7d22dd0
Task-number: QTBUG-85447
Change-Id: I381d31c95bcdab26147a331444ba40c7af9d0a95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
So that the correct version is generated in top-level builds.
Change-Id: I360370815ce178564cc79157dc61d70adfd4f947
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
CMake makes possible to specify a target in the target_link_library
call even if the target is not declared yet. This adds flexibility to
the target declaration arrangement. For the Qt modules we have to
restrict freedom, because of the .prl files generating. If the Qt
module depends on another Qt module, the dependecy must be declared
before the module finalizing step, otherwise this will cause invalid
records in the module .prl file.
TODO: The dependency order issue could be solved by using conditional
genex's when generating step1 .prl file. But we ask developers to
depend on Qt module targets that have been defined before their usage.
Fixes: QTBUG-89467
Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The find script checked for UIKIT which is set during a Qt build
in QtPlaformSupport.cmake but is not set when building a user project.
This casused the find script to skip the iOS specific code that
passed the -framework OpenGLES linker flag.
This broke SDK switching in Xcode.
Check the IOS variable instead which is set by CMake for all projects
that pass -DCMAKE_SYSTEM_NAME=iOS.
Pick-to: 6.1
Change-Id: I9bd088f317917544ccfeff61fc4ff90f18f0f3d8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Before this change, we created a CMake toolchain file for iOS and
macOS universal which propagated the initially configured
CMAKE_OSX_ARCHITECTURES values to user projects.
So if Qt was configured with 2 arches, configuring a CMake user
project using the generated toolchain file would also build the
user project targeting those 2 arches.
The reason for this that the same toolchain file is used for
configuring both Qt and users projects and we needed to ensure that
other Qt repos are built with the same set of arches. That
unfortunately led the multiple arches to carry over into user
projects.
This is different from qmake behavior which configured user projects
with 1 arch only.
Instead of the toolchain file explicitly setting
CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of
arches into QT_OSX_ARCHITECTURES.
Then if the toolchain file detects that we're building a Qt repo (by
checking for the presence of QT_REPO_MODULE_VERSION) set
CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the
initial list of arches.
For user projects we want to have some sensible defaults.
For macOS projects, leave the decision of the architecture to build
to CMake.
For iOS Xcode projects, leave the decision to Xcode.
For iOS Ninja projects, set the architecture to the first value of the
architectures used when configuring Qt.
As a side note this fixes an issue in our CI where we configured macOS
Qt with 2 architectures and then tried to run CMake build tests for
both architectures on a machine that doesn't have the universal SDK.
This led to build failures.
Because the CMake build tests act as regular user projects, now they
are configured with a single architecture that is automtically
detected by CMake.
Pick-to: 6.1
Task-number: QTBUG-85447
Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The CoreMotion is required by the QtSensor module.
Task-number: QTBUG-92502
Change-Id: I7f1853131aa96b2cb052862d5bf492df5ec18150
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The 'list(TRANSFORM cmake_args REPLACE "\\[\\[;\\]\\]" "\\\\;")' call
breaks the list arguments added when evaluating the 'INPUT_' values.
Therefore, it's necessary to apply bracket-based escaping to all list
arguments instead of the standard escaping.
Amends 856fadf85c
Fixes: QTBUG-92459
Change-Id: Ifd4e0ca5f549a1c7fab9ceb587ed355250c4e677
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Expand the condition without an extra negation.
This fixes incorrect condition evaluation for conditions not enclosed
in parenthesis.
Pick-to: 6.1
Change-Id: I4923059b6b199676058091c23d51c9368daaebd0
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously the plugin .pri files that CMake generated for qmake
consumption contained an '-' to exclude the plugin from
auto-importing only if the plugin type was generic or a platform
plugin.
Now that plugin projects that should be excluded have a proper
DEFAULT_IF FALSE
clause, we can simply query for the defaultness of the plugin
to know whether to exclude it in the generated .pri file.
This fixes an issue with Qt static builds and qtvirtualkeyboard.
The vkb plugin was not excluded and thus any simple QtGui app
linked to the vkb plugin in a static qmake project. This led to linker
issues because the vkb plugin also depends on a vkb quick plugin which
is not listed as a dependency.
Augments 76230d9879
Amends c975c35eae
Pick-to: 6.1 6.1.0
Fixes: QTBUG-92529
Task-number: QTBUG-87861
Change-Id: I9671f6504374cf0799289bbe19110e01c129402e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_internal_add_executable has some special logic to link static
plugins in order to avoid issues with link cycles on exported
Qt module targets. This logic does not take into account if a plugin
is a default plugin.
On windows this caused duplicate symbol linking issues in static super
builds, because both qwindows and qdirect2d define a subset of
the same symbols.
Make sure to only link to default static plugins.
This will skip linking to qdirect2d because it's not a default qpa
plugin and thus avoid linker issues.
Amends 5807e1ae81
Pick-to: 6.1 6.1.0
Fixes: QTBUG-92451
Change-Id: I56df2ce0201625088417de53038642518c1d3bbd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake 3.20.0 can create autogen-related cyclic dependencies that are
only detected at build time by Ninja, which then fails with a build error.
Warn and advise to use a different CMake version instead.
Pick-to: 6.1 6.0
Change-Id: I9bef973ad2efdb69f28d6a9e0584b543be59f17f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Plugin meta-sets are not visible outside of the module build tree, so
there is no point in adding dependencies for externally added plugins.
Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_TESTCASE_BUILDDIR was implicitly defined by Qt::Test target for
library users in Qt5. By default, this definition will point to
CMAKE_CURRENT_BINARY_DIR. This logic works similarly to qmake logic.
From user's perspective it might be useful to not rely on standard
search paths, but specify own. This can be done by setting the
QT_TESTCASE_BUILDDIR property for the user's target. CMake will
substute the value of the QT_TESTCASE_BUILDDIR property into the
QT_TESTCASE_BUILDDIR definition.
The implicit QT_TESTCASE_SOURCEDIR also seems to be useful. According
to the current logic, it points to CMAKE_CURRENT_SOURCE_DIR.
Fixes: QTBUG-92079
Change-Id: I8a9065f08e859c713b3c8cc08142a9ced0677770
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The generated object resource library depends on the Qt::Core library
because uses the functions defined in qresource.cpp. Dummy linking of
the Qt::Core to an object library has an effect only when the object
library is linked directly to the executable as a target. If we link
the object library as INTERFACE library we miss out all the objects
that need to be linked to the executable. This behavior is explained
here:
https://bit.ly/3sFWKvI
Thus, the only option to link the object library objects to the
endpoint executable is to use TARGET_OBJECTS property in genex, as
it's already done. But that means we are losing all profits that
target actually has, especially linking the object library dependencies.
The combination of both of the above methods does the job. The only
thing that looks fragile so far is order. Currently, the order we
use in the target_link_library call applies to the linker command line.
This means the object library objects must always appear before the
object library target.
Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Plugin targets don't fit the requirements of the module but use
the function associated to the module. The purpose of using
qt_internal_module_info is to get the path to the top-level include
directory. So there is no point in breaking the encapsulation rules
to get a well-known directory.
Change-Id: If3d2a31d4ec186929e3d662a79a1ae9eac988d1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use the same approach we use for iOS, which is to set multiple
CMAKE_OSX_ARCHITECTURES values and let the clang front end
deal with lipo-ing the final libraries.
For now, Qt can be configured to build universal macOS libraries by
passing 2 architectures to CMake, either via:
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
or
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Currently we recommend specifying the intel x86_64 arch as the first
one, to get an intel slice configuration that is comparable to a
non-universal intel build.
Specifying the arm64 slice first could pessimize optimizations and
reduce the feature set for the intel slice due to the limitation
that we run configure tests only once.
The first specified architecture is the one used to do all the
configure tests.
It 'mostly' defines the common feature set of both architecture
slices, with the excepion of some special handling for sse2 and
neon instructions.
In the future we might want to run at least the Qt architecture config
test for all specified architectures, so that we can extract all the
supported sub-arches and instruction sets in a reliable way.
For now, we use the same sse2 hack as for iOS simulator_and_device
builds, otherwise QtGui fails to link due to missing
qt_memfill32_sse2 and other symbols.
The hack is somewhat augmented to ensure that reconfiguration
still succeeds (same issue happened with iOS). Previously the sse2
feature condition was broken due to force setting the feature
to be ON. Now the condition also checks for a special
QT_FORCE_FEATURE_sse2 variable which we set internally.
Note that we shouldn't build for arm64e, because the binaries
get killed when running on AS with the following message:
kernel: exec_mach_imgact: not running binary built against
preview arm64e ABI.
Aslo, by default, we disable the arm64 slice for qt sql plugins,
mostly because the CI provisioned sql libraries that we depend on only
contain x86_64 slices, and trying to build the sql plugins for both
slices will fail with linker errors.
This behavior can be disabled for all targets marked by
qt_internal_force_macos_intel_arch, by setting the
QT_FORCE_MACOS_ALL_ARCHES CMake option to ON.
To disble it per-target one can set
QT_FORCE_MACOS_ALL_ARCHES_${target} to ON.
Task-number: QTBUG-85447
Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
qt_internal_add_simd can now take an EXCLUDE_OSX_ARCHITECTURES list of
values which specifies for which architectures the simd compile flags
should not be added.
This is relevant for macOS universal builds.
Example
CMAKE_OSX_ARCHITECTURES is "x86_64;arm64"
EXCLUDE_OSX_ARCHITECTURES is "arm64"
SIMD is avx2
the final compiler flags that will be added are "-Xarch_x86_64 -mavx2"
Slightly, clean up the function implementation and document its
arguments.
NAME handling has been removed because it's dead code that hasn't been
removed as part of 1b7008a3d7.
Task-number: QTBUG-85447
Change-Id: I395c19bdd67219bebb6b5b8d9f418b6e6488e09b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A few configure defines get changed:
QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE
QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY
QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE
device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1
To create source maps for debugging. use
device-option QT_WASM_SOURCE_MAP=1
Task-number: QTBUG-78647
Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Whenever something went wrong with building the arch test or extracting
info from it, the failure messages lacked useful details.
It's especially hard to figure out what went wrong if the failure
happened in the CI.
Print a bunch of useful information in case of failure.
Change-Id: Iafe287f951880c1441e57924ae372d6a9029a9a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
On Windows, we need to strip drive letter and colon before prepending
DESTDIR when creating our versioned hard links.
This fixes CI submodule updates.
Change-Id: I41bc5f27b714ef74d3fadc4a0fb16c3d8b20da1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 88886f193230292f38987ac4f1503753f50786f0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
qt3d/9a473a3c9b246f4895ae73d7060745b8b199a6c5 introduced a find_package
call in a configure.cmake file, very subtly breaking top-level builds
with configure.
The find_package call results in errors of the cmake call that runs
QtProcessConfigureArgs.cmake (see bug report for details).
Create a find_package stub that errors out with a helpful message.
Task-number: QTBUG-92163
Change-Id: I06db0bf219b965e93b78c690e9f7ad868196ddb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake 3.19 removed the restrictions on allowable names for properties
on INTERFACE targets. With earlier CMake versions (back to CMake 3.11),
names for custom properties must begin with either a lowercase letter
or an underscore.
In 5807e1ae81 (Add plugins to Qt tools and executables for static
builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and
QT_REPO_PLUGINS were used, but in some cases, the targets on which they
were being set are INTERFACE targets. Replace these with names that
are supported with CMake 3.11 or later.
Amends 5807e1ae81
Task-number: QTBUG-91915
Pick-to: 6.1
Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the recent refactoring of qt_internal_add_plugin, a new target
existence check was added when associating a plugin with a qt module.
That check didn't account for a qualified qt module target name.
This failed configuration of qtsvg which checked for the existence of
a namespace-less 'Gui' in a per-repo build.
Make sure to prepend the Qt namespace to the qt module name and also
handle aliased target names.
As a drive-by, add a TODO item to figure out how to link executables
to plugins who's plugin type belong to a different repo, but both the
executable and plugin are built in the current repo.
Amends aa4a1006cb
Fixes: QTBUG-92235
Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
list(TRANSFORM ...) unexpectedly removes semicolon escaping in list
items. So the list arguments seems to be broken. The 'bracket argument'
suppresses this behavior. Right before forwarding command line
arguments to the cmake call, 'bracket arguments'are replaced by escaped
semicolons back.
Recent fix escapes all semicolons of the 'configure_args' and glues
all arguments to a single 'list'.
Amends df8e1c8e58
Change-Id: I4a458b9e3add307b36924c4c7c7f739d348f9343
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If SKIP_INSTALL option is specified for the qt_internal_add_plugin
function the install_directory variable become empty and finalizer unable
to call qt_finalize_plugin, because of lack of the second argument. It
makes sense to use the INSTALL_PATH single argument instead.
Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove code duplication by calling qt6_add_plugin() from
qt_internal_add_plugin().
Separate out the public and internal arguments for the
variables defined in QtBuild.cmake for these functions.
Provide them via commands instead for greater robustness.
This separation allows other Qt repos to access the appropriate
set of keywords where they define commands that forward
on to *_add_plugin() in their implementations. Retain
the old variables for now to simplify the integration
steps for updating other repos. The old variables can
be removed once there are no more references left to
them in any repo.
Task-number: QTBUG-88763
Pick-to: 6.1
Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building and installing a Qt repo that provides plugins for a Qt
module within a different repository (for example, qtimageformats
providing imageformat plugins for QtGui), re-configuring that repository
would result in configuration errors like
"add_library cannot create ALIAS target "Qt6::QTgaPlugin" because
another target with the same name already exists."
This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled
in the Qt6*PluginConfig.cmake files that create imported targets for the
plugins we want to build.
To fix this, when building Qt, we now load only plugins that are
provided by repositories the currently building repository depends on.
We read the repo dependencies from dependencies.yaml when the
Qt6BuildInternals package is loaded, but only in static builds and only
if we're currently building a Qt repository.
To find out whether we're building a Qt repository, we check whether
QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT,
because that variable is not available for the first find_package calls
in the repository's top-level project file.
In each Qt6*PluginConfig.cmake file, we bail out if the plugin's
repository is not one of the ones in QT_REPO_DEPENDENCIES.
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the option argument INSTALL_VERSIONED_LINK to qt_internal_add_tool
and qt_internal_add_app. For tools/apps with this argument we create an
install rule that creates a versioned hard link. For example, for
bin/qmake we create bin/qmake6.
Note that this only applies to prefix builds.
Apply this argument to qmake.
The qt_internal_add_app change is necessary for qtdiag and in qttools.
Task-number: QTBUG-89170
Change-Id: Id32d6055544c475166f4d854aaeb6292fbb5fbb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit c19d957f45fa27f61b5ecc566f8dbc19f12a44c3)
In the CI on a windows we configure Qt with the following prefix
-DCMAKE_INSTALL_PREFIX:PATH=\Users\qt\work\install
Note the lack of the drive letter.
This is intentional, so that we can abuse CMake's DESTDIR installation
mechanism to install into a custom path.
This causes trouble for static Qt builds in the CI.
Specifically when there is no qt.conf file next to qmake, qmake -query
will report a
QT_INSTALL_PREFIX:/Users/qt/work/install
and ultimately qmake will fail to locate the module .pri files in such
a path, showing errors like:
Project ERROR: Unknown module(s) in QT: core gui?
If a qt.conf is placed next to qmake (even an empty one), a differenct
code path is used in qmake to resolve the prefix, which returns a path
with a drive letter.
In a shared build, because the 'relocatable' feature is enabled by
default, a different code path is used and thus the prefix is
also successfully resolved.
So the problem is specific to static Windows Qt builds that have no
qt.conf file next to qmake.
This is the exact scenario that we encounter when running static
Qt tests (tst_qmake in particular).
To circumvent the issue, prepend a drive letter to the prefix
hardcoded into qconfig.cpp. Do that with
get_filename_component(REALPATH) which apparently resolves
to a fully qualified path.
Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I17c885f29bfdee45bec1d6aac7c3b26723e761a3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The code was added as part of
a6ccef651d
but the important bits were removed as part of
c431e2d33c
Change-Id: I6ba7bffa2bfdbeae2c92cd9ffeaa5f31771eedde
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Passing e.g. -- -DQT_BUILD_SUBMODULES="qtbase;qtdeclarative" to
configure would fail because the module list was not preserved
as a single argument.
Change-Id: If685d0d541201597a2c2a5dc3d55b5d1ae51da22
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In static builds, we cannot allow any part of the main build to make a
call to find_package(Qt6...) where such a call may load a
Qt6*Plugins.cmake file. That would add additional dependencies to the
main module targets, setting up a circular dependency in the set of
*Config.cmake files which cannot be resolved. This scenario would be
triggered by per-repo builds or user projects.
But Qt's tools and other executables still need to load some plugins
in static builds. Sometimes a platform plugin may be enough, other
times we may want all supportable plugins (e.g. Qt Designer).
Therefore, add all plugins we can identify as relevant for an
executable that is part of the Qt build, but add them directly to the
executable without affecting the linking relationships between the
main module libraries.
Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in
top level builds because there should be no difference between per-repo
and top level builds any more (as far as linking static plugins is
concerned).
Examples that build as part of the main build will still build
successfully after this change, but they will not run if they require
a platform plugin. Examples need to be moved out to a separate build
where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS
set to TRUE to be runnable (see QTBUG-90820).
Fixes: QTBUG-91915
Pick-to: 6.1
Change-Id: I8088baddb54e394ca111b103313596d6743570ba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On BSD systems backtrace lies in libexecinfo. Use
FindBacktrace from CMake to be able to resolve
backtrace on more unixes than linux.
Change-Id: Ie14fd1727d2da03645fc2d6de10c0217baabad6b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The $<NOT:...> genex already guarantees to return a value of 0 or 1,
so there's no need to wrap it with $<BOOL:...>.
Pick-to: 6.0 6.1
Change-Id: Iff4ad64ed8deaa846e1b5bc22d2e5d9dbcd77cc7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Using CMAKE_C_COMPILER to match the compiler
has its drawbacks. CMAKE_C_COMPILER can include
the whole path to the compiler and directory
names that incude icc, icl or qcc also match
even if the compiler is not icc or qcc.
Icc has the compiler id Intel according to
the CMake documentation.
The compiler id for qcc is QCC according to
CMake policy 0047, and this is set to new since
Qt requires CMake to be above 3.0.
Change-Id: Iceb428ed10f0f5bbaa19ec2d883da186c85e7a73
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Set QT_DEFAULT_MKSPEC for various bsd systems, this is needed to
find qplatformdefs.h when compiling.
Change-Id: I9450193b737930548f32c87be3525c5ecd1e0e13
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In particular that influences BundledLibrary targets.
Most internal targets already depended transitively on Qt::Platform
via Qt::Core as a public dependency. This was not the case for
BundledLibrary targets which don't link to Qt::Core.
This led to compilation issues in user projects when targeting
WebAssembly, due to mismatched flags between a bundled Harfbuzz vs
a user project. Probably other subtle issues as well (e.g. none of the
Windows specific compile definitions were passed to bundled libs).
Bundled libraries depend on PlatformCommonInternal already, so make
PlatformCommonInternal turn depend on the public Platform target.
I thought that was already the case, but we merely relied on the
Qt::Core dependency.
Note that Qt::Core should still list Platform as a public dependency,
so it gets propagated to user projects.
Amends acf9b3a68b
Change-Id: Ida3b219818f89ec6eba2c2d92c5db65ad56bc5a4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A call to file(WRITE) will unconditionally update the file's timestamp
even if the file's contents don't change. The *Plugin.cpp file was
being written using configure_file() which avoids that, but the .cpp.in
file it was configuring from was being written out using file(WRITE)
every time CMake ran. Autogen saw that file as a dependency and then
regenerated the mocs_compilation.cpp file, which in turn results in
unnecessary rebuilds and relinking when nothing is actually changing.
The file(WRITE) - configure_file() dance is no longer needed anyway,
since the generated *Plugin.cpp file is very simple with no
substitutions required. Therefore, we can simplify that file's
generation with a single file(WRITE) that only executes if the file
contents will change or the file is missing.
Pick-to: 6.1 6.0
Change-Id: I2b7d1ff678b85ea7811969d656555592c9b6865f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When configuring a benchmark using the standalone-test script the
'benchmark' target is not available, causing a configure error.
Pick-to: 6.1 6.0
Change-Id: I8e480c9e72b47783c0910428187f0092049e89db
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In shadow per-repo builds we never hit the code that is supposed to
install cmake/Find*.cmake files. This caused problems when statically
building a Qt repo like qtshadertools against qtimageformats which
provides such Find*.cmake files.
Fixes: QTBUG-91538
Change-Id: I1147daee817ac71303d93e8bf368b2769afb0bb4
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The change "Enable X11 on other platforms than just Linux"
uses qt_set01 in a configure.cmake file but does not add it
to the stubs list in QtProcessConfigureArgs.cmake thus
breaking builds based on configure.
Add a defstub with qt_set01 to fix this.
Change-Id: Ia3e0ec61df5228f88f77f631968f6f96d567ec8e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
androiddeployqt relies on *-android-dependencies.xml files to know
what dependencies like jar files and permissions a Qt module requires.
CMake create those files under Qt prefix's lib dir but CMake was not
accounting for module plugins.
Fixes: QTBUG-90812
Pick-to: 6.1 6.0
Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt is built with CMake since 6.0 and the QMake build system was removed
in 6.1. It's time to remove the -cmake and -qmake configure arguments
for Qt 6.2.
Fixes: QTBUG-88286
Change-Id: Ie726ec364ded025f8d93bd69b469561a6ae40aa9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building a module against an installer-provided Qt,
CMAKE_INSTALL_PREFIX would default to /home/qt/work/install, which is
the install prefix of our packaging machines.
Do not hard-code the install prefix in QtBuildInternalsExtra.cmake but
use the one that is calculated from the location of
QtBuildInternalsExtra.cmake.
Pick-to: 6.1
Fixes: QTBUG-90449
Fixes: QTBUG-91475
Change-Id: I39f214efb18796a89f00a171ef190c547bba5c0a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For each plugin, we create a custom target with it's OUTPUT_NAME such
that one simply can do 'ninja qtuiotouchplugin' to build it.
QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is
problematic with Makefile generators on case-insensitive file systems.
See CMake upstream issue #21915 for details.
Work around this issue by not creating the custom target in this
situation.
Pick-to: 6.1
Fixes: QTBUG-84342
Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now that we're not actually using qmakeconfig.cpp anymore, we can remove
it together with all qmake-related information that was written into
qconfig.cpp.
This also moves the qtConfEntries array back to qlibraryinfo.cpp.
Change-Id: I5e57d8c55613332cc3e57b11df4398d46aed259b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those have fixed values.
Change-Id: I7f1ba8036f43413d3c805f4b419ae79e037343fb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Includes both minimum deployment targets and minimum sdk
versions.
As per supported Apple platforms versions which was done
in qt/qtdoc at
8807fdedce29cbbd7662fcd745234da30eace3fb
For Qt for iOS 6.0.x we only bump the minimum
deloyment target because applications seem to crash with iOS 12.4+,
and it's better to have a build error than a runtime error.
The minimum required sdk will not be bumped for 6.0.x, so we don't
accidentally break someone's existing build, given that 6.0 is already
released.
Pick-to: 6.1
Task-number: QTCREATORBUG-23574
Change-Id: I3046384164f2d7fdbd0cfd16dcb85e0d60bc56ce
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Associated changes in the qtdeclarative repo now ensure that arguments
for qml plugins are handled on the calling side. This reduces the
qml-specific logic needed in qtbase and gives qtdeclarative clearer
control over qml build and install locations.
As part of that work, the INSTALL_LOCATION keyword used in
qt_internal_record_rcc_object_files() has been renamed to
INSTALL_DIRECTORY to make it consistent with the keyword used for the
same concept in other commands.
Pick-to: 6.1
Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Features that are not emitted in the current
configuration (e.g. plugin-manifests on Linux) should not yield an
error. Instead, print a warning message like Qt5's configure did.
Set insignificant feature to OFF.
Remove the now unneeded emit_if parameter from
qt_feature_set_cache_value.
Pick-to: 6.1
Fixes: QTBUG-88305
Change-Id: I0f2ce152fca5f08417038c9bd2c07639ff6a3df4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
With the existing types we can only display a list of features or
whether a feature is on or off, but we cannot display arbitrary values.
Using the new message type, it is possible to show paths or versions as
summary entries.
Change-Id: I5d16cb4b30923f3566755bd4d7440bdd1ece82f5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
configure.cmake files are read twice when using the configure script /
qt-configure-module: First, when configure is running and a second time,
when CMake creates the local build system files.
In the first run, not every function and esp. no targets are
available. Code in configure.cmake that accesses targets or calls
functions unknown to configure will fail at the configure stage.
This patch introduces the QT_CONFIGURE_RUNNING variable that can be used
in configure.cmake files to guard such code:
if(QT_CONFIGURE_RUNNING)
set(_qt_coord_type double)
else()
get_property(_qt_coord_type TARGET Qt6::Core
PROPERTY INTERFACE_QT_COORD_TYPE)
endif()
Change-Id: Iff39924d6a5133379d28c8204d7b7afdf47de5c8
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Fix the name in the function's doc comment and error messages.
Pick-to: 6.1
Change-Id: I918db802a0dbb0508f65d227f7c896d2ad0beeae
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
To not disturb the qmake build we kept syncqt.pl in <src>/bin but
installed it to libexec. This is not necessary anymore.
This also removes the need for having syncqt.pl in both, bin and libexec
in the build dir of qtbase.
Pick-to: 6.1
Fixes: QTBUG-91076
Change-Id: I44b014ea41e3f00c420e02fd5c76f11169340b8c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
QtAutoDetect.cmake did read the (possibly detected) toolchain file and
looked for the string "The Android Open Source Project" to deduce that
we want to build for Android. This has been done, because we're
autodetecting the platform before the first project comment, i.e. before
the toolchain file is loaded.
This magic string detection is a bit fragile, and we need a similar
approach for WebAssembly. A more robust approach would be to fetch the
value of CMAKE_SYSTEM_NAME from the toolchain file without actually
loading it.
Now, we run a CMake script that includes the toolchain file and prints
variables were interested in. The calling code reads these variables and
stores them in prefixed variables in the current scope.
Change-Id: Ide9ea3054e1453d17129523e1ec86ecaed55af2a
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
c++latest does check that our headers also work with upcoming C++20
support in MSVC. It also implicitly sets -permissive-, which checks for
stricter standards compliance.
Pick-to: 6.1
Task-number: QTBUG-91117
Change-Id: Iaf1547191969213d570a1b2f59888ad04a7977ab
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
When packaging different Qt versions for Linux distributions (or any
distribution with a common bin dir), Qt tools cannot be installed to
/usr/bin, because the executable names of the different Qt versions
clash.
To solve this conflict, our recommendation is to install Qt's tools to
/usr/lib/qt6/bin and to create versioned symlinks to user-facing tools
in /usr/bin.
User-facing tools are tools that are supposed to be started manually by
the user. They are marked in Qt's build system. Distro package
maintainers can now configure with
-DCMAKE_INSTALL_PREFIX=/usr
-DINSTALL_BINDIR=/usr/lib/qt6/bin
-DINSTALL_PUBLICBINDIR=/usr/bin
and will find a file called user_facing_tool_links.txt in the build
directory after the cmake run. Nothing will be installed to
INSTALL_PUBLICBINDIR.
Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR.
Example content:
/usr/lib/qt6/bin/qmake /usr/bin/qmake6
To actually create the versioned symlinks, the content of this file can
be fed to ln like this:
xargs ln -s < build-dir/user_facing_tool_links.txt
Or the package maintainer may decide to do something completely
different as suits their needs.
This patch adds the USER_FACING argument to qt_internal_add_tool to mark
tools as user-facing. In addition, every Qt created by
qt_internal_add_app is treated as user-facing.
The only tool this patch marks as user-facing in qtbase is qmake.
Pick-to: 6.1
Fixes: QTBUG-89170
Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Contrary to its name, this command was also setting a target property.
Since it was only called in one place and that caller can just as
easily set the property instead, rename the command to make clear its
internal nature and refactor it so that the caller is responsible for
setting that property instead.
Also make it an error rather than just a warning if the command is used
for a target that doesn't belong to any module. Since this is now
unambiguously an internal command, we should always expect the target
to belong to a module.
Pick-to: 6.1
Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since the QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH definitions keep the same
value in modern CMake build, no need to have special handling in cases
where these values are used in qmake. Also it will be useful to
specify the relative path to the prefix directory from the directories
different of 'bin' when use QMakeLibraryInfo.
Task-number: QTBUG-75870
Change-Id: I5a777001eb334dcf05e22853a514d4257352d59b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Move the qmake-specific logic of the QLibraryInfo class to
qmake internals. 'qconfig.cpp.in' now stores information about
the library info entries to keep them consistent between qmake
and the Core library. qmake requires specific features enabled
in the Core library, so building qmake will be skipped if the
features are not enabled.
All flags directly related to the qmake have been removed from
Core lib.
Remove all bootstrap related sections from qmake CMakeLists.txt
Task-number: QTBUG-89369
Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The code branch for the INTERNAL argument did nothing, and we never call
qt_internal_add_linker_version_script with INTERNAL.
Change-Id: Ie369b4dac29cd1a977433ebfd662c198a3e1d0f2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Putting each keyword on its own line makes it much easier to read and
improves maintainability. It is friendlier to source control when
keywords need to be added or removed.
This commit introduces no functional change.
Pick-to: 6.1
Change-Id: I79efd039e5afa5f11f1d859405d6487ad6b3beb2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In static per-repo builds, we have a mix of targets provided by
packages and targets provided by the main build. For the builds that
create the packages, we must avoid adding a dependency for the main
module library target on its associated plugin targets or else the
package config files end up with a cyclic dependency that cannot be
resolved when something tries to consume them. This only happens for
static builds because we have been attaching a linking relationship
to the main module library that isn't really a true dependency, we
attached it only for convenience of things linking to that module
library.
To preserve that convenience linking without breaking the config
packages, we use the QT_NO_CREATE_TARGETS condition to prevent CMake
seeing that relationship when generating the *Config.cmake files.
Creating these relationships will be delayed until the plugin's
*Config.cmake file is loaded, at which point it will add itself to
the main module library's imported target INTERFACE (this was already
done before, we just now rely solely on that).
Task-number: QTBUG-90819
Pick-to: 6.1
Change-Id: Id725742182bcda64841be84fe1650bafb9151bb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The pro2cmake.py conversion script faithfully reproduced the .pro files
for the plugins, which specified the libraries as public. But in CMake,
the implications of this are that public usage requirements should then
be propagated to consumers. We don't expect any consumers, since a
plugin is created as a MODULE library in CMake, so for Windows we don't
even have an import library to link with. The only exception to this is
for static builds where plugins are created as STATIC libraries
instead, but only in certain controlled situations do we then link to
plugins. Even then, usage requirements are not expected to propagate to
the consumers, so these relationships should always be specified as
private.
This change warns on any PUBLIC usage requirements specified for a
plugin. This check is disabled by default to avoid spamming CI builds
for repos that haven't been fixed yet. The check can be enabled by a
CMake cache option, which is intended for developers to use locally
when fixing this issue in other repos (all plugins in qtbase should
not trigger this warning as a result of changes in this commit).
Task-number: QTBUG-90819
Pick-to: 6.1
Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][Build System] Tools that are called by the build system and
are unlikely to be called by the user are now installed to the libexec
directory.
This is a step towards easier co-installability of different Qt
versions.
Pick-to: 6.1
Task-number: QTBUG-88791
Change-Id: Id19575b5ba27795f7715e4ea6a09391b26dd4942
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We had two workarounds:
* script that adds Gui to tests
* create a symbolic link for the qt install dir to fake_prefix which
androiddelployqt was expecting them to be under
Both issues are fixed, thus removing the workarounds.
Pick-to: 6.1 6.0
Change-Id: Ic022bece15afe92c693d573893d260b13b4227ed
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
QMake used to allow retrieving the Android features list for a modules.
The dependencies are written to *-android-dependencies.xml files and are
read by androiddeployqt. This option was missed at some point along the
way of writing CMake port for Qt 6.
Pick-to: 6.1 6.0
Change-Id: Ic0b82f024567e640968f97aeff2db1888f2b53a5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This will be used to access host tools that are installed in
${prefix}/libexec instead of ${prefix}/bin.
Pick-to: 6.1
Change-Id: I36c4b5736330f8229d267a117c65d55cd5e12758
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Initial replacement of boolean INPUT_ variables to the FEATURE_
variables was wrongly changed to updating of the INPUT_ variable
value to ON/OFF value. This causes potential issues when INPUT_
variable has explicit check for 'yes' or 'no'.
The feature evaluation step enables FEATURE_ variables in case if
the corresponding INPUT_ variable contains a positive CMake value.
So there is no need to process boolean INPUTs at the argument
processing step.
Also no need to keep the special opengl case, since it will be
processed correctly.
Fixes: QTBUG-91158
Pick-to: 6.0
Pick-to: 6.1
Change-Id: I96bb7903a904ae3cf788d7ef7d4e0c019046eb95
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add the INSTALL_DIR argument to qt_internal_add_tool to allow
installation of tools in other locations than INSTALL_BINDIR.
Pick-to: 6.1
Task-number: QTBUG-88791
Change-Id: I88ede81a4c13c82f6d209156d3801ce130f8fc10
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The headers are already somewhat tested with C++17 in the regular
build. So let's try in the headers_clean check with C++20 instead.
Using C++20 with MSVC 19.28 doesn't work yet though:
corelib/tools/qalgorithms.h(247): error C2039: 'popcount': is not a member of 'std'
corelib/tools/qhashfunctions.h(311): note: see declaration of 'std'
corelib/tools/qalgorithms.h(247): error C3861: 'popcount': identifier not found
...
Task-number: QTQAINFRA-4242
Change-Id: I1b48bcb9656fe1587fe03d3a17e3484c693aa295
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Tests should follow their default output of txt as when run directly,
and any output configuration should be handled by the CI system.
Change-Id: Id0d72318df5edad1c58ac637e827d6043884e829
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Toni Saario <toni.saario@qt.io>
comply with the api version used by default with androiddeployqt and
in docs. Google play also requires api 29 as minimum.
Task-number: QTBUG-90943
Pick-to: 6.1 6.0
Change-Id: I05e2a90b4d7f2120b0198e3fb7b8b1b2398eba93
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Normal Android apps require Qt::Gui dependency and since tests don't
need to handle any special cases for an app without Qt::Gui, let's add
it by default.
This also will allow us to remove some workarounds done on CI side to
run tests for Android.
Fixes: QTBUG-90870
Pick-to: 6.0 6.1
Change-Id: I845650c17a1b73e4c4977043f863ec44e50f06c3
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
We must not guess the compiler from the -platform argument if one of the
following holds:
- the CXX/CC environment variables are set
- the CMAKE_CXX_COMPILER/CMAKE_C_COMPILER variables are passed
Pick-to: 6.1
Fixes: QTBUG-90914
Change-Id: Iff7a0e7b8857f77333f1705f118d7952af5234ba
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The attempt to call target_link_libraries on OpenSSL::Crypto failed when
this target was added as UNKNOWN library by FindOpenSSL.cmake.
Instead, set the INTERFACE_LINK_LIBRARIES property directly.
Pick-to: 6.1 6.0
Fixes: QTBUG-90925
Change-Id: Idbc1379c89480225fc7a8d417416ed20404a1122
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When a feature is set in qtbase and is later set to another value,
an error occurs and an error message is given. This patch
changes the error message to contain both the preexisting and the
new value
Change-Id: Ifa9fc1f06bfde40e8fd5dfdf30165d4393abbd28
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This prevented androiddeployqt from properly deploying libraries which
specify init class via the ":" delimiter.
Pick-to: 6.0 6.1
Change-Id: Ib9cfa7edc864d7d540577df22284ceb9714a2511
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Keep the c++2a feature, but make it an alias for compatibility
purposes.
Pick-to: 6.1
Change-Id: I6f153109be84659806f1b7a57a88a187875166d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This is supposed to be mapped to INSTALL_TRANSLATIONSDIR, not
INSTALL_TRANSLATIONDIR (without the s).
Pick-to: 6.0 6.1
Fixes: QTBUG-90946
Change-Id: Icec93ffc0dc80d9ac7cf6cf1b13824bc2a1e795f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The unquoted 'string(FIND ${toolchain_file_content} ...)' call fails for
multiline content of the variable toolchain_file_content, so add
quotes around, fixes:
[...]
CMake Error at cmake/QtAutoDetect.cmake:42 (string):
string sub-command FIND requires 3 or 4 parameters.
Call Stack (most recent call first):
cmake/QtAutoDetect.cmake:311 (qt_auto_detect_android)
CMakeLists.txt:19 (include)
[...]
-- Configuring incomplete, errors occurred!
in case the given toolchain file starts with multiple lines
in the first 80 characters, e.g. in the case of buildroot:
#
# Automatically generated file; DO NOT EDIT.
# CMake toolchain file for Buildroot
#
[...]
Task-number: QTBUG-90980
Pick-to: 6.0 6.1
Change-Id: I8e038e08d83016e8253f2e83b2efb8f06034c6cd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Developer builds with RelWithDebInfo should also make benchmarks, it
is how we get good traces.
Change-Id: I009d40580d5d784f78bd18ebf21887ce3c1fa97d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In apple systems it's necessary to pass the framework paths to the moc
generator to resolve required header files. We need to collect framework
paths for all INCLUDE_DIRECTORY_TARGETS and add them to the command line
of the moc generator.
Task-number: QTBUG-84906
Change-Id: I9e6356e7e0a5f2493823ec764a48b0b8f1c8c10d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using static OpenSSL, HAVE_openssl test will fail, because of
unresolved external symbols. These symbols are from Ws2_32.lib and
Crypt32.lib, which CMake does not link by default. In qmake build
system, we can use OPENSSL_LIBS variable to specify these system
libraries. But there is no similar variable in CMake build system.
Accordingly, we should let OpenSSL::Crypto target link these libraries.
Upstream issue:
https://gitlab.kitware.com/cmake/cmake/-/issues/19263
Pick-to: 6.0
Change-Id: I5f27790b251d0a0f71aaf2aed2b933aeb3326f1f
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add internal function to cleanup compiler flags out of the
CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear
the '/EHsc' flag for the MSVC compiler family. This adjusts the
CMake behavior to the qmake one.
Change the 'EXCEPTIONS' option handling in helper functions. Add
ability to add enabling and disabling exception flags. Previously
it was only possible to add disabling exception flags.
Fixes: QTBUG-89952
Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Header files of a Qt module are usually found in subdirectories.
Avoid creating object file paths like "header_foo/bar.h.o".
When building with conan, the "header_foo" subdirectory was not created
for whatever reason.
Now, we make sure we have clean object file paths, e.g.
"header_check/foo/bar.h.o", and we create the directory upfront before
invoking the compiler.
Fixes: QTBUG-90529
Change-Id: Ifa5d6b97e07fc4e249c58cda5128439d60b14f5f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
(cherry picked from commit 54980200c79b466a276a4d3054390e4b3162e9ed)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Commit 18fc9e1bf8 introduced a
Windows-only QT_TOOL_PATH_SETUP_COMMAND to make it possible to
call the tool of a module while building the module itself.
The "set PATH=..." command in QT_TOOL_PATH_SETUP_COMMAND was flawed,
because it contained escaped double quotes which made the set command ineffective.
Fix this by removing the escaping of the double quotes.
This was uncovered when porting qtscxml to CMake.
Change-Id: I5909aa841e7895d6d0feb4037a935b805ccfdc99
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to
identify prefix of 'Qt<version>HostInfoConfig.cmake'.
Qt<version>HostInfo is not found, if project version differs
from qtbase version.
Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE'
variables to 'QtBuildInternalsConfig.cmake'. In this case
variables will be exposed for a wider list of internal routines.
Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find
Qt<version>HostInfo module.
Fixes: QTBUG-90345
Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add CMake upstream(3.20.0) version of FindPostgreSQL.cmake, to avoid
server-related headers lookup.
Avoid using the Qt version of the PostgreSQL module, if it's
older than the CMake's one.
Fixes: QTBUG-89639
Change-Id: I71a0c3508000901969933aea8a08d1ad431db711
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By not including ASM in the languages for which compiler flags are
adjusted, we can end up with inconsistent optimization and debug
settings between different languages. Make sure they are treated the
same.
Similarly, linker flags for MODULE target types should also have their
debugging and incremental linking flags adjusted, just like EXE and
SHARED targets. When building with MSVC, MODULE targets were having
the relevant flags stripped, but not then replaced with the desired
ones, leaving them empty in typical scenarios. This would primarily
affect plugins, which are built as MODULE rather than SHARED libraries.
Fixes: QTBUG-90237
Change-Id: I648ea74be1654d24cbecc592ce0ca4b59b2ae839
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make the document reflect the current status of the port.
Also link to https://doc.qt.io/qt-6/build-sources.html and
https://wiki.qt.io/Building_Qt_6_from_Git as official sources
on how to build Qt. This document should IMO rather
concentrate on documenting the build system internals.
Pick-to: 6.0
Change-Id: If62cb966b41b7452edb5b63725756916b66affac
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a repository != qtbase, like qtactiveqt, QMAKE_PRL_LIBS
contained entries like Qt6Core and Qt6Widgets, meaning the linker line
would contain exactly these arguments.
When building an activeqt example with qmake, the link then failed with
"LNK1181: cannot open input file 'Qt6Widgets.obj'".
The correct entry would have been $$[QT_INSTALL_LIBS]/Qt6Widgets.obj.
Fix this by determining the full path to the import library in the first
step of the prl generation. This enables QtFinishPrlFile.cmake to
recognize Qt6Widgets as Qt module and generate the right QMAKE_PRL_LIBS
entry.
Pick-to: 6.0
Fixes: QTBUG-90520
Change-Id: Id0d9178da0e0dfc3ea4fadbbe8f5900d792ffc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add '_WINDLL' definition for the MSVC compilers family.
Check the 'FEATURE_optimize_size' value before replacing compiler flags
in the qt_internal_add_optimize_full_flags function. This is required,
because Qt::Core and Qt::Gui modules lost their ability to shrink,
when selecting the appropriate build type or features.
Fixes: QTBUG-89952
Change-Id: I982c25ea84e4793b4006ead0ee516b3f3eb2a054
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit d0071a4f87 broke static top-level builds:
CMake Error at .../qtbase/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake:17 (set_property):
set_property can not be used on an ALIAS target.
Fixed by moving the un-aliasing of the target before the set_property
call.
Pick-to: 6.0
Change-Id: I96c731353798a58ff9b3a664f3614ef03c897dcb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Projects may call find_package(Qt6 ...) multiple times. When enabling
examples and tests, this happens a lot. For a statically built Qt,
for modules that have plugins (e.g. Gui), every time the module's
config file was loaded, it was generating and adding another copy of
the import plugin sources to the module target. These accumulated and
created many duplicates, which in turn blew out generation time and
made the build very inefficient.
This change checks whether the import plugin sources have already been
processed for the module target and ensures they are only added once.
It records its status on the target itself so that both local and
global targets are supported.
Fixes: QTBUG-90465
Change-Id: I1f45b1ee771a933ee755d44f1e983d6d9113dad0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This property is dynamically determined and set in the
Qt6${module-name}PluginsConfig.cmake files now.
There is no need anymore to export this property.
Change-Id: I2d164864c4099034b88f9ad852eae8b9f9e55f8b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When doing a per-repository build of Qt, as it is done for the installer
packages, the build of qtbase has no knowledge of plugins that might be
built and installed from other repositories. That means we must not
write a fixed list of known plugins when exporting Qt modules of qtbase.
In particular, qtsvg adds imageformat plugins that are supposed to be
picked up by qtbase's QtGui module when linking a project against a
statically linked Qt.
${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the
include statements for qtsvg's plugin config files and operated on a
fixed list of plugins, all from qtbase.
Apart from that, the Qt6::Gui target's property QT_PLUGINS did only
contain the qtbase plugins.
This patch fixes the situation in the following way:
1. All Qt6*PluginConfig.cmake files in
${install-prefix}/lib/cmake/Qt6Gui are detected and included.
2. From those file names, the target names of the plugins are
deduced. This is safe as the file name of those generated files is a
direct result of the plugin's target name.
3. The QT_PLUGINS property of the module is updated with the detected
plugin target names.
Fixes: QTBUG-89643
Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
'qt_manual_moc' doesn't provide include paths for 'moc' command to
substitute required macros. This change adds the
'INCLUDE_DIRECTORIES' and 'INCLUDE_DIRECTORY_TARGETS' arguments to
the 'qt_manual_moc' function.
If 'INCLUDE_DIRECTORY_TARGETS' is specified, 'qt_manual_moc'
collects 'INTERFACE_INCLUDE_DIRECTORIES' of provided targets and
uses them as the 'moc' include directories.
Change-Id: I58c8887dae3ca2484574c5e12e2cbd47f5bd3648
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just like config_module_name is appended by "_private" in the case of
internal module pri, replace module_includes with the private one.
It fixes the issue where a pro file that uses an internal module pri
does not build due to missing paths to private headers.
Fixes: QTBUG-89961
Change-Id: Ice16a1e9f709d29454f1ddf5b954673cc06a88bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
Make sure to react on failed syncqt runs during the CMake run.
CMake will now report something along this:
```
syncqt couldn't parse .../qt5/qtbase/sync.profile: Can't modify modulus (%) in scalar assignment at .../qt5/qtbase/sync.profile line 25, near ");"
CMake Error at qtbase/cmake/QtModuleHelpers.cmake:192 (message):
Failed to run syncqt, return code: 255
```
Change-Id: I575a5fc926c547b6b633583e5d675f7e35beb734
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a Qt module against an installer-provided Qt on macOS, the
module pulls in the headersclean feature that creates the *_header_check
targets. Those targets try to compile the public headers of the module,
and the compilation command contains the -iframework argument. That
-iframework argument is supposed to point to the directory where the Qt
libs are installed. However, it pointed to the original
CMAKE_INSTALL_PREFIX of the machine where Qt was packaged.
Use the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable instead
that contains the real installation location, even for an
installer-provided Qt.
Pick-to: 6.0
Fixes: QTBUG-90402
Change-Id: I27de8b3cc816488c2716042383b334d5c421452d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move UNICODE and _UNICODE definitions from the public Qt::Platform
target to the private Qt::PlatformCommonInternal target.
Fixes: QTBUG-89951
Change-Id: Ib4c1c4cab74acda0a43c4ddb3cffd3954393dc89
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace package _LIBRARIES by _LIBRARY and _INCLUDE_DIRS by
_INCLUDE_DIR. Move find_package_handle_standard_args for Oracle and DB2,
since this call should set _FOUND variable but not separate condition.
Fixes: QTBUG-89866
Change-Id: I54be2c2c4d7ba4b849a27139702861ecd937c444
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be able to link a Release user project against a RelWithDebInfo Qt we
set several IMPORTED_*_RELEASE properties in
the *AdditionalTargetInfo.cmake file of each Qt module.
The EntryPoint module however is a bit special as it is an
INTERFACE_LIBRARY linking publicly against a static
library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file
was almost empty, because qt_internal_export_additional_targets_file was
called before EntryPointImplementation was set up. Also,
qt_internal_add_module, which calls
qt_internal_export_additional_targets_file, does not know that we want
to export the EntryPointImplementation target.
We fix this by telling qt_internal_add_module(EntryPoint) to not
generate the *AdditionalTargetInfo.cmake file and call
qt_internal_export_additional_targets_file later to take the targets
EntryPoint and EntryPointImplementation into consideration.
qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to
turn off the generation of *AdditionalTargetInfo.cmake files.
Pick-to: 6.0
Fixes: QTBUG-90039
Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The QtBuildInternals config package file gets processed before feature
evaluation occurs. That means INPUT_pkg_config may be defined, but the
corresponding FEATURE_pkg_config variable won't have been set/updated
yet. Do this check locally because the availability of a number of
features is conditional on whether pkg-config is available.
Change-Id: I6030eb380ee0c630ffbe5db5eed397a46227c7f6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an optional argument to store the report command while feature
evaluation-only stage. This is necessary, because according to the
actual feature evaluation process, evaluation happens only once and it's
impossible to record any command during the evaluation-only stage.
Fixes: QTBUG-90319
Change-Id: I215fbe0a28a2661cd2d97d253b2e2c787d295cbd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Functions in QtFlagHandlingHelpers.cmake try to update the CMake cache
variables for compiler and linker flags. These were using the current
value of those variables and writing the modified ones back to the
cache every time CMake ran. If a toolchain file sets or modifies any of
these variables, that updated value is used and written back into the
cache instead of the original cache variable's value. The next time
CMake executes, the toolchain file re-applies the same change and the
variable grows longer each time with flags repeated. With Ninja, this
causes a complete rebuild every time CMake is re-run. The Android NDK
toolchain file is one example where this behavior is triggered (the
fault is shared, one could argue that the NDK should only be setting
..._INIT variables, but that's out of our control).
Another related bug in the previous implementation was that the flags
used to build after the first CMake execution could be different to
those used for all builds after the second and later CMake runs. This
is because the CMake cache was being updated, but not always the
calling scope of the functions that modified them. If a toolchain file
set any of the compiler or linker flag variables as non-cache
variables, then updating the cache variable would have no effect on
the calling scope. The non-cache variable would continue to take
precedence for that scope for that run. The next time CMake executes
though, the updated cache variable would now have been used by the
toolchain file and the change *will* be part of the non-cache
variable's value.
The above are examples of why you should try to avoid updating these
cache variables from project code. We could leave the cache alone and
always update only non-cache variables, but then a developer looking
at the cache may wonder why the values they see there don't match the
values being used in builds. Or worse, they think the cache values
are being used and don't realize the builds are using something
different. Ultimately, we have to choose which downside we are happy
to live with. The changes here preserve the previous intent of
updating the cache, but it's still a bit fragile.
Fixes: QTBUG-89821
Task-number: QTBUG-85992
Task-number: QTBUG-86866
Change-Id: I8a16753e159bde338e6d2e5dd2ce91fc8ac5c39d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Ubuntu 20.04 is a supported platform and comes with CMake 3.16. The
current state of the Qt build works fine with this CMake version, mainly
because the default build on Linux is single-config.
For multi-config builds we have higher version requirements as
documented in cmake/README.md.
This lowers the barrier for users using single-config builds who don't
want or cannot upgrade to CMake >= 3.18.
For Ninja Multi-Config builds, which were introduced by CMake 3.17, we
yield a warning that 3.18.3 is the lowest supported version.
Pick-to: 6.0
Change-Id: Ia918b9f2b494508e86301ffc0e138d3ad4dbaf86
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
CMake <= 3.19 adds the '-fno-fat-lto-objects' compiler flag
unconditionally when CMAKE_INTERPROCEDURAL_OPTIMIZATION is enabled.
This is fine for shared libraries but static ones need the opposite
compiler flag.
Task-number: QTBUG-89426
Pick-to: 6.0
Change-Id: Ie5f48178803a270f6d94408f7a8e85d379eb123c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since test command variable may contain quotes, there is a warning
in generated test wrappers related to 'message(FATAL_ERROR', that
should display full command in log in case of error. To avoid any
complicated quoting of command to only display it, join command into
single string in wrapper script and pass resulting variable to
'message(FATAL_ERROR'.
Pick-to: 6.0
Change-Id: Ie990fc0b0bf2c19b119c7c4e2aeec092e5200103
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use upper-level document build directory for generated .qch files. This
avoids copying of .qch with html documents and duplicating them in
the installation directory.
Pick-to: 6.0
Change-Id: I63b2de0047005419d352ea259dec6f17a826a477
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In latest Oracle Instant Client releases for windows the OCI library
name is 'oci.dll'. Add it as option to find_library call.
Change-Id: I6e6f4a998207d16583a380c1bd95db857051606b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add explicit error, if multi-config build is requested, but selected
generator doesn't support it.
Fixes: QTBUG-88287
Pick-to: 6.0
Change-Id: I6dba589bb59ad69fa07221c657df272ec75c359b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add output of feature condition error at the end of configuration
summary. Introduce qt_configure_add_report_error that may be used
to add error to end-point configure report without actual
configure interruption.
Fixes: QTBUG-88282
Change-Id: Idcf478da863ae6507438eb3370927d7d1f01e071
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 642ee46f98.
Reason for revert: Issue when command_count is actually 0
Pick-to: 6.0
Change-Id: I1b2603f25b56e3bd50cfc22a08925930ad231498
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use LESS_EQUAL condition since qt_configure_command_count stores last
added command index but not actual count
Fixes: QTBUG-88054
Pick-to: 6.0
Change-Id: I8112820f9885bdad5a786a4f6b4890d8f2fbe14b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use the QT_MKSPECS_DIR instead of QT_SOURCE_TREE to find out the
location for the testserver feature's data. QT_SOURCE_TREE points to
qtbase source location, which may not be always available. This allows
to use this feature by projects outside of qtbase.
Task-number: QTBUG-85034
Change-Id: If7fa6ef95777be9acf35d36f8d99776bf9568a79
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Introduce a new QT_TESTSERVER_COMPOSE_FILE variable for setting a custom
docker compose file path, which can be set by projects outside of qtbase
(e.g. QtCoap). If the variable is not set, fallback to the compose file
located in qtbase.
Task-number: QTBUG-85034
Change-Id: I4c0c9b161cad9787b089ef7e9da2aa00352a9159
Reviewed-by: Cristian Adam <cristian.adam@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>
With Ninja Multi-Config, QMAKE_LIBS_FOO_DEBUG and QMAKE_LIBS_FOO_RELEASE
are generated, if their values differ. In that case we did not create an
empty QMAKE_LIBS_FOO assignment. That, however, is needed to make the
library 'foo' known to qmake_use.prf.
This amends bd98ba0d17.
Fixes: QTBUG-89387
Change-Id: I80e23746e6ba6ff7f5f4186116232395814cee15
Reviewed-by: Cristian Adam <cristian.adam@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>
Build qtbase with -DFEATURE_static_runtime=ON, and then separately build
another module, following build error occurs:
error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'.
That's because all the sources in this module are compiled with 'MD'.
When separately building a module except qtbase, FEATURE_static_runtime
is not exist in cmake cache. So we should use QT_FEATURE_static_runtime
instead of FEATURE_static_runtime in qt_set_common_target_properties.
Additionally, adjust the indentation.
Pick-to: 6.0
Change-Id: I2cf4737db9d3e8533570039a66c7d277d62a8d14
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using MSVC compiler and -DFEATURE_static_runtime=ON, qrc_foo.cpp
and qtentrypoint_win.cpp are still compiled with '-MD' or '-MDd' flag,
which will cause following warnings and other possible problems:
warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs;
use /NODEFAULTLIB:library
Pick-to: 6.0
Change-Id: I6794930a64e9cff4dc1c9632fc3fc64227848af0
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The scripts that are used by Android test VMs are now located in qtbase
and are not easily usable by other modules. To fix that and allow other
modules to use those scripts, we install them with cmake into libexec.
Task-number: QTQAINFRA-4052
Pick-to: 6.0
Change-Id: Ibdd3658fd9fe7e007104a85d9999028a2de99a33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Wrap benchmark executable target with cmake script to run it on windows
without necessity of environment variables set.
Move common logic related to test and benchmark environment to
'qt_internal_collect_command_environment' function.
Make error message of wrapper script a bit more verbose.
Amends 61d5b01972
Task-number: QTBUG-89076
Pick-to: 6.0
Change-Id: I6ad3a027dc071176070cf3af4cf306f20d652039
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Refactor test adding procedure. It's expected that for each new
platform we prepare test executable and arguments first and then
pass them to common test adding section.
Rename '_qt_internal_wrap_test' to 'qt_internal_create_command_script'
Rework paramerters handling of 'qt_internal_create_command_script',
make them named.
Add 'qt_internal_create_test_script' to add tests and wrap them using
'qt_internal_create_command_script'.
Amends f19266bd02
Fixes: QTBUG-88053
Pick-to: 6.0
Change-Id: I812f4a295005bf3a85cdcb5b8c41180f8249dc96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt-cmake-standalone-test would be looking for the config files under
the target machine install prefix instead of under the staging prefix
on the build host.
Change-Id: I29850af6d8fe502f4944f689ec10539d17ccdcb9
Pick-to: 6.0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use 'separate_arguments' to explicitly split arguments from environment
that form 'COMMAND' for execute_process. Enclose using bracket syntax
arguments, that propagated to wrapper script as pure strings.
Amends f19266bd02
Pick-to: 6.0
Change-Id: I858ddff7efa281f9cecfda656a02e1fd12361758
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This was needed, when the mkspecs directory was not present in the
non-prefix build directory. That's not the case anymore.
Pick-to: 6.0
Fixes: QTBUG-89182
Change-Id: I2b04c2d857b0af324e1d7c41ed1934a62275d6f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There is no point in generating cpp files containing Q_IMPORT_PLUGIN()
macro calls for non-executable targets like modules, plugins and object
libraries in a static Qt build.
It causes unnecessary compiling of 10+ files for each of those targets.
In a static Qt build, plugin imports should only be done for executables,
tools and applications.
Pick-to: 6.0
Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Disabled by default as they are currently not being built and many are
not working properly, this will allow us to start using them again.
Change-Id: I823368d04e9fde2beccabedc3ca15efd1f355bfb
Pick-to: 6.0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In some case CROSSCOMPILING_EMULATOR property is not INHERITED and is
set to 'NOTFOUND' by get_test_property. Force it to empty string in
this case.
Add missed 'name' argument to '_qt_internal_wrap_test'. 'name'
previously was used from parent scope.
Pick-to: 6.0
Fixes: QTBUG-88053
Change-Id: I5286bcb9b11659f638e178ce52172dfee994fc34
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add custom targets with '_benchmark' suffixes to make run of
benchmarks using generators possible, e.g.:
$ ninja tst_bench_qudpsocket_benchmark
Extend '-[no]make' option to pass benchmark. Rework
'-[no]make' processing to unify these options processing.
Also looks like it doesn't make sense to enable benchmarks without
having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own
dependency automatically.
Task-number: QTBUG-89076
Pick-to: 6.0
Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When a CMake release introduces a new policy that affects most Qt
modules, it may be appropriate to make each module aware of that newer
CMake version and use the NEW policy without raising the minimum CMake
version requirement. To reduce the churn associated with making that
change across all Qt modules individually, this change allows it to be
updated in a central place (qtbase), but in a way that allows a Qt
module to override it in its own .cmake.conf file if required (e.g. to
address the issues identified by policy warnings at a later time). The
policies are modified at the start of the call to
qt_build_repo_begin().
For commands defined by the qtbase module, qtbase needs to be in
control of the policy settings at the point where those commands are
defined. The above mechanism should not affect the policy settings for
these commands, so the various *Config.cmake.in files must not specify
policy ranges in a way that a Qt module's .cmake.conf file could
influence.
Starting with CMake 3.12, policies can be specified as a version range
with the cmake_minimum_required() and cmake_policy() commands. All
policies introduced in CMake versions up to the upper limit of that
range will be set to NEW. The actual version of CMake being used only
has to be at least the lower limit of the specified version range.
This change uses cmake_minimum_required() rather than cmake_policy()
due to the latter not halting further processing upon failure.
See the following:
https://gitlab.kitware.com/cmake/cmake/-/issues/21557
Task-number: QTBUG-88700
Pick-to: 6.0
Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Wrap Qt tests to handle TESTRUNNER and TESTARGS environment variables.
Variables are handled according to qmake build procedure. All test
now are wrapped by generated CMake script.
Fixes: QTBUG-88053
Pick-to: 6.0
Change-Id: I339977ce6ce11ddd38a4bf0bd26eb8f2ae463ba3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want to remove the Qt .pro files for projects, except examples,
because examples are still meant to build with qmake.
To not lose coverage on examples built with qmake, add instructions that
will build the qtrepo/examples folder with qmake when the CMake
configuration has -DQT_BUILD_EXAMPLES=ON.
This means that such configurations will build examples both with CMake
and qmake.
Aside from making sure that our examples will still build with qmake, it
will gives us some some coverage that a CMake-built qmake works
correctly.
Implementation-wise, add new instructions files that can call qmake and
make depending on configuration and target type.
Pick-to: 6.0
Fixes: QTBUG-85986
Change-Id: Ie8f4cbcda03c94da2aef455e32f48dad41a4bdb0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qmake build system defines _CRT_SECURE_NO_WARNINGS in
mkspecs/features/qt_module.prf, the cmake build system should do the
same thing in qt_internal_add_module().
Adding this definition can avoid warnings like:
warning C4996: 'strncpy': This function or variable may be unsafe.
As a special case, Bootstrap uses add_library() instead of
qt_internal_add_module(), so _CRT_SECURE_NO_WARNINGS should also be
defined in src/tools/bootstrap/CMakeLists.txt.
Pick-to: 6.0
Change-Id: Ic82193d177f82785fd84948efa78c49ca8d8db46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I'll preface by saying, it's not clear to me why the behavior is
different.
Our qt_run_config_test_architecture function builds a target
executable, and then uses file(STRINGS) to try and parse out some
magic strings that we expect the executable to have (architecture,
abi, etc).
In qmake this was done by matching with a regular expression ending on
a \\0 null byte character.
In CMake, we do a string(FIND) and string(SUBSTRING until the end of
the line) on a *line* returned from file(STRINGS). Notably, I did not
find any regexp syntax provided by CMake to try and match a null byte
character.
Note the docs for file(STRINGS) implies to me that *lines* are
detected by looking for newline characters '\n'. The docs also
mention that binary data in the file is ignored. What's binary
data though?
If you open the executable with a hex editor, at least on macOS, the
strings we are interested in are indeed separated by null byte chars,
not newline chars.
On most platforms file(STRINGS) did end a line on the null byte
character.
Except, for some reason not when building Qt for the oss-fuzz project
with clang under Docker.
Calling message() on one of the lines prints a very long string with
null characters seemingly replaced with semicolons, and of course the
matched architecture string is wrong and fails configuration.
For *some reason*, if I add a "REGEX ==Qt=magic=Qt==" option to the
file(STRINGS) command, the captured output lines don't contain
semicolons even when building for oss-fuzz.
The extracted strings are then correct, and configuration succeeds.
Use the REGEX option workaround, with the aim to quickly fix Qt
building for oss-fuzz for 6.0.1 release.
Pick-to: 6.0
Fixes: QTBUG-89047
Change-Id: Iad11c1090c1187aadd39082f196050bf3290df95
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QMake libraries that contain dashes are referenced by QMAKE_USE as is,
but the corresponding QMAKE_LIB_<NAME> variable must be normalized to
contain underscores.
Example from the qmake build:
./mkspecs/modules/qt_lib_waylandclient.pri
11:QT.waylandclient.uses = wayland-client xkbcommon wayland-cursor
./mkspecs/modules/qt_lib_waylandclient_private.pri
12:QMAKE_DEPENDS_WAYLAND_CURSOR_CC = WAYLAND_CLIENT
13:QMAKE_DEPENDS_WAYLAND_CURSOR_LD = WAYLAND_CLIENT
15:QMAKE_LIBS_WAYLAND_CURSOR = -lwayland-cursor
Pick-to: 6.0
Change-Id: If31bd45764d52f97d80d6388503008dc1ffb16ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Which is probably the direct port of -nomake XXX, as qmake
always offered the way to build tests/examples/etc. after
configuring without, while cmake doesn't.
Pick-to: 6.0
Change-Id: I85b039e56cde3ddfaf661385100d3c3a8cc2ac16
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those entries were always empty. The INTERFACE_QT_MODULE_USES property
was never set.
Map each public dependency to its qmake lib name and place this value
into the module's QT.<module-name>.uses variable.
Take into account the "_nolink" target modifier and translate it to
qmake's "/nolink".
Pick-to: 6.0
Fixes: QTBUG-88951
Change-Id: Ib6ef65b842a1fe1da3ade55867583343b4ee76ee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rename QT_QMAKE_LIB_TARGETS_foo to QT_TARGETS_OF_QMAKE_LIB_foo, because
we want to introduce the counterpart QT_QMAKE_LIB_OF_TARGET_bar in a
subsequent commit.
Pick-to: 6.0
Task-number: QTBUG-88951
Change-Id: I33f00f4fe65c5977da6e74c632ebeab3b891c89a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider a qmake lib 'foo' that doesn't have entries in
QMAKE_LIBS_FOO. Then we must not discard this entry in the generated
module pri file, because otherwise any attempt to QMAKE_USE 'foo' will
fail with the error message "Library 'foo' is not defined.".
Pick-to: 6.0
Task-number: QTBUG-88951
Change-Id: Ibed283857f5f66b1b79459fe7b7cf06c7ce0691d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add '_qt_internal_dump_expression_values' function that dumps all
values evaluated by 'qt_evaluate_config_expression'.
'_qt_internal_dump_expression_values' doesn't evaluate undefined
features, only collect actual values.
Fixes: QTBUG-88476
Pick-to: 6.0
Change-Id: I9d09ffbd9f9fa91bc4f36536c58e7f118b06f9b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Despite being installed in the the binary directory, this
CMake snippet cannot be executed.
Pick-to: 6.0
Change-Id: Ibfd31e51184f0688d19ac063804cc200c95555a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, the prl files always assumed that resource object
files are installed into $qt_prefix/lib when doing a prefix build.
That was true for qt_internal_add_resource calls, but not for
qt6_add_qml_module and qt6_target_qml_files.
Change qt_internal_record_rcc_object_files to take a new required
INSTALL_LOCATION argument. The argument takes a path relative
to CMAKE_INSTALL_PREFIX.
Modify __qt_propagate_generated_resource to save the relative path of
the generated resource source file, which will be used in the
computation of the final resource object file location.
This is needed because the Qml resource functions place the source
files in a different directory layout, e.g. .rcc vs .qmlcache
Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/
instead of $$[QT_INSTALL_LIBS]/ for the resource install paths.
A follow up patch is done in qtdeclarative to pass the new
INSTALL_LOCATION argument from the Qml CMake functions.
Amends f9dcade5e7
Task-number: QTBUG-87702
Task-number: QTBUG-88425
Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Follow the pattern recommended in the CMake docs for the $<JOIN:...>
generator expression. Wrap it in a $<BOOL:...> genex so that if a
target's INCLUDE_DIRECTORIES property is empty, we don't add a
stray -I with no directory following it. This fixes the following error
when running qdoc:
qdoc: Missing value after '-I'.
Pick-to: 6.0
Task-number: QTBUG-88838
Change-Id: Ie3ef2625fbb29cc501f7fc22ff7a9cc8ac548322
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If CMake version is 3.19 or greater, use cmake_language(DEFER CALL)
for Qt internal scope finalizers, instead of the homegrown
implementation.
Apart from not depending on the hacky homegrown solution, it
significantly improves the readability of --trace-redirect logs.
Pick-to: 6.0
Task-number: QTBUG-77377
Change-Id: I5ce374bb313865662c536826e86052bc762438b9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On DLL platforms, the value of QMAKE_PRL_TARGET should be the import
library (foo.lib), not the actual DLL (foo.dll). The genex
TARGET_LINKER_FILE_NAME provides exactly that.
Fixes: QTBUG-88864
Pick-to: 6.0
Change-Id: I553930bb840007772fe8f4612f95e0e320f54107
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed
property names from INTERFACE libraries. And it was the wrong thing
to do as well. Prefix the properties with INTERFACE_ as appropriate.
Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only
modules to the headerclean compile commands. This causes configuration
issues with UiPlugin in qttools. Fortunately it seems that qmake
doesn't do that for 'header_module's either.
Finally don't query for the FRAMEWORK property on the passed target
(INTERFACE libs can't be frameworks). Instead just query if the whole
Qt build itself is a framework build.
An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking
headersclean add_custom_commands for UiPlugin in qttools. To avoid
this the property was renamed to all lower case in
6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate
issue, but it's possible it might resurface in the future with a
different property name that wasn't renamed. In particular I thought
it might happen with QT_NO_UTF8_SOURCE but it didn't.
In case something like that happens again, the two possible solutions
are to bump minimum CMake version requirement to 3.19 (where upper
case property names are allowed to be queried from INTERFACE libs) or
to implement recursive include directory fetching similar to our
qt_internal_walk_libs implementation.
Pick-to: 6.0
Task-number: QTBUG-86053
Task-number: QTBUG-82615
Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Query the include dirs from the INTERFACE_INCLUDE_DIRECTORIES property
when generating docs for an INTERFACE library.
Amends 2db41fefa0
Pick-to: 6.0
Task-number: QTBUG-88838
Change-Id: Ic8a454ba66b2dbc59bad883e1e0d38ebb26d0370
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Restore 'QT_STAGING_PREFIX' logic when generating
'qt-cmake-standalone-test'. Relative paths now calculating depend on
'QT_STAGING_PREFIX'. For prefix builds QT_STAGING_PREFIX should be
prepend to '__qt_cmake_standalone_test_path'
Fixes: QTBUG-88764
Pick-to: 6.0
Change-Id: I655c60847f2ab872948cfe9aedc27835e5cc4fb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and include it in QtBuild.cmake.
Commit e8d8b1a5e4 added two different code paths to include
QtBuildInternalsAndroid.cmake.
This was needed, because:
In a top-level build, we must not include files that are not yet
installed. We have the source tree available, and
"${QT_SOURCE_TREE}/cmake" is in CMAKE_MODULE_PATH.
We can use the "module syntax" of the include() command.
In a per-repository build, when building against an installed qtbase, we
must not include files of the source tree, because that's not guaranteed
to be available. However, Qt6BuildInternalsConfig.cmake is installed,
and we can directly include QtBuildInternalsAndroid.cmake, which is
right next to it.
We can circumvent this whole issue by moving the Android-related
functions out of the Qt6BuildInternals package and including it in
QtBuild.cmake.
Pick-to: 6.0
Task-number: QTBUG-88718
Change-Id: I5192ba19bb77952505c20d053d7285f798d16ac5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Commit 9e0fb9c4fb introduced build
failures in non-top-level builds when building Qt modules against
qtbase.
This was observed on in the CI for CentOS.
Partly revert above commit by taking the old code path for non-top-level
builds.
Fixes: QTBUG-88718
Change-Id: I8926e1e4628ec5bdcea99e10497c1f65c10d072d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 510186a218e63c88100efc38cb1611f122f94570)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
For consistency, apply the following renamings:
QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT
QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT
QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT
BUILD_EXAMPLES -> QT_BUILD_EXAMPLES
BUILD_TESTING -> QT_BUILD_TESTS
This should help to better convey the difference between "BUILD" and
"NO_MAKE".
To configure tests, but not to build them by default, pass the
following to CMake:
-DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF
Analoguous for examples:
-DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF
Tools can be excluded from the default build with:
-DBUILD_TOOLS_BY_DEFAULT=OFF
The variable BUILD_TESTING is still available and initialized with the
value of QT_BUILD_TESTS.
Pick-to: 6.0 6.0.0
Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Plugins will no longer get .pri files generated in non-static builds.
Header modules are now marked in the .pri files as CONFIG += no_link.
Pick-to: 6.0 6.0.0
Fixes: QTBUG-88221
Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
During a top-level prefix build, while configuring qtsvg,
Qt6BuildInternalsConfig tries to include QtBuildInternalsAndroid.cmake
but such files are not copied by qt_copy_or_install() at configure
time.
We need to use the "module" form of include() to take CMAKE_MODULE_PATH
into account. Then QtBuildInternalsAndroid.cmake can be loaded from the
source tree.
The include's current form was introduced in commit
3cb9ee3a5b without further
explanation. Assuming an accidental change.
Pick-to: 6.0 6.0.0
Task-number: QTBUG-88460
Change-Id: If06ac715fae3c2bebbeffca44b7e07265ffb0f71
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move 'INPUT_' variable detection logic out of
'qt_feature_set_cache_value' function. Use 'INPUT_'
variable to enable/disable related 'FEATURE_' in case if
'FEATURE_' is not defined.
Fixes: QTBUG-88501
Pick-to: 6.0 6.0.0
Change-Id: I1162ac0fb562036898a37b52c3f80229ec8a0970
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a target for each level-1 subdirectory in a module. Ninja already
generates phony targets such as "qtbase/src/all", but those are not
available in e.g. IDE integrations of CMake. With this addition, targets
like qtbase, qtbase_src, and qtbase_tests are available in IDEs.
Pick-to: 6.0 6.0.0
Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For shared build, Qt6BundledHarfbuzz.lib and Qt6BundledPcre2.lib are not
installed. But their pri files(qt_ext_harfbuzz.pri, qt_ext_pcre2.pri)
and debug info files(Qt6BundledHarfbuzz.pdb, Qt6BundledPcre2.pdb) are
still installed. These files should not be installed too.
Pick-to: 6.0.0 6.0
Change-Id: I3e54bec01d94ee3897b485a982d01b24edc602aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Updates due to newer compiler version in QNX7.1
Task-number: QTBUG-88300
Change-Id: If9bbc08d49a077d80174a1807e069b5d4ef61c0d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use lowercase underscored property names. This ensures they will
continue to work even for INTERFACE libraries if it ever comes to
that.
Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This function will be used by qtdeclarative CMake functions to record
resource object file information for Qml-specific generated resources
(like the ones containing qmldir and qml files).
Task-number: QTBUG-87702
Change-Id: I17c295821775d005dea82d9fbdf83d7ee613f615
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMake build of Qt intends to improve the developer experience in
regards to static Qt builds and Qt resource files. Specifically with a
CMake build of Qt, Qt developers don't have to manually call
Q_INIT_RESOURCE anymore.
For details see the following commits
e343affd63e817ac3d684ab5432081
The last commit's implementation is incomplete though.
To ensure successful linking, each target's prl file should contain
not only the resource object files that are assigned to the target,
but also all resource object files of the target's dependencies.
To achieve that, qt_collect_libs will now recursively collect all
resource object files assigned to the QT_RCC_OBJECTS property of each
dependency.
Note this implementation is still incomplete. We do not export rcc
object file information in the CMake Targets files.
That means that when configuring qtdeclarative in a
non-top-level build, the generated Qml prl file will not
contain references to Core's mimetypes resource object file, etc.
So with the current change, only the object files that are part of the
current CMake configuration build are tracked.
Exporting the resource object files locations proves in a format
usable for prl files proves to be difficult (due to CMake not
supporting exporting genexes in random properties) and will have to be
addressed in a separate change.
Amends 4ab5432081
Task-number: QTBUG-88425
Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Refactor the function in preparation of processing rcc object files.
Introduce 2 new functions to get and set values in the memoization
dictionary used by qt_internal_walk_libs.
Modify qt_internal_add_target_aliases to assign the alias names it
creates as properties on the target.
Extract these aliases when available to assign memoized values not
only for the initial library name, but also for its aliases.
When recursively calling qt_internal_walk_libs, make sure to provide a
unique out_var name based on the outer target name, and not just
lib_libs. Otherwise the out_var values would be polluted from
previous recursion runs.
Make sure to check for -NOTFOUND in if() checks so that we reuse
memoized values that are the empty string.
Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In qt_internal_create_module_depends_file we're checking the target
property INTERFACE_MODULE_HAS_HEADERS. However, this property is not
exported, and in per-repo builds we do not have access to this.
As we cannot export INTERFACE_* properties, we export another one,
called _qt_module_has_headers.
This amends commit 598e873c84.
Fixes: QTBUG-88503
Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make paths in qt-cmake-standalone-test relative to script's PWD.
Fixes: QTBUG-88380
Change-Id: I6ab507c31ebed391f4e85bc6fe3f7f747dd97d54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Without breaking currently generated CMakeLists
Fixes: QTBUG-88549
Change-Id: Ibda643e1374d9024bf693c12de8ec0ac46e09b7b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
That breaks configuration with CMake version 3.18.x (but not 3.19 for
some reason).
Specifically configure ends up passing -DCMAKE_CXX_COMPILER=clang++
which overrides the compiler set by the CMake Android toolchain file,
and at the very end of CMake's configuration it complains about
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= clang++
Which suddenly starts another configuration with the modified
compilers, ends up detecting host compilers and libraries and
basically everything breaks apart.
Fix QtProcessConfigureArgs.cmake not to pass the compiler options if
the mkspec contains 'android'.
Who knows, we might need this for other platforms too at some point.
Task-number: QTBUG-88460
Change-Id: Idd57870a7cb1009a4e7802e5b3d5ac735f2dacf6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Although many executable files were generated by qt_internal_add_tool().
Some executable files like designer and androiddeployqt were generated
by qt_internal_add_app(). Some executable files like windeployqt were
generated by qt_internal_add_executable(). For these executable files,
their PDB files won't be installed on MSVC platform, and their separate
debug info won't be generated and installed on other platforms.
To fix this, qt_enable_separate_debug_info() and
qt_internal_install_pdb_files() should also be called in
qt_internal_add_executable().
Fixes: QTBUG-88268
Change-Id: Id6a3b5842dba325166e3d696701c82ad942bca74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Updates one 3rdparty CMake file from
https://github.com/KDE/extra-cmake-modules to include support for
fuzzing.
Task-number: QTBUG-88429
Change-Id: I19e7ed3c5602c34ba4b86e6b0df2ea3047c7c9e6
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In multi-config build, for different configs, the pdb files of EXEs
should have different installation directories.
For example, when CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug,
<build_dir>/bin/moc.pdb will be installed to <install_dir>/bin/moc.pdb.
<build_dir>/bin/Debug/moc.pdb should be installed to
<install_dir>/bin/Debug/moc.pdb, not <install_dir>/bin/moc.pdb.
Fixes: QTBUG-88268
Change-Id: Idc7c92ca8d44bb81d990656af2b309306a4f5c6b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Android *.so files need to CXX visibility to default after
qt_set_common_target_properties() which was setting it to hidden.
Also, pass the correct androidtestrunner arguments for cmake check
target
Fixes: QTBUG-88228
Change-Id: Ia29cdc9e65153c9669f3ec06f74a46f8fcd8c507
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EntryPoint interface target now contains all the logic
for what flags and optional static libraries to add when the
entrypoint is enabled.
The target property QT_NO_ENTRYPOINT can be used to disable
the entrypoint.
Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix the overly strict regex in qt_internal_create_module_depends_file to
allow for - and _ in module names.
We had the above mentioned dependency cycle, because the module name
Core_qobject was translated to just Core, creating a Core -> Core
dependency.
Amends da7609e7d0.
Fixes: QTBUG-88437
Change-Id: I866f7ce31e9a1b92fe4c0a6450295c2f3c761558
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since feature evaluation expects explicit 'no' value for INPUT_opengl
to disable either desktop or es2 opengl support, add special
processing for -no-opengl option into QtProcessConfigureArgs.cmake
Task-number: QTBUG-88142
Change-Id: Ib49123ee3e9f98035f6ec85a182382559f4db478
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All configure arguments should be processed as strings
and not be ignored if they satisfy CMake's FALSE criteria
(see https://cmake.org/cmake/help/latest/command/if.html)
Fixes: QTBUG-88424
Change-Id: I932038ad3c5999bed58957dec51fbf892bd650d7
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>
According to Microsoft's docs, /OPT:ICF is enabled by the
linker by default unless /OPT:NOICF or /DEBUG is specified.
If we are in RelWithDebInfo mode, /DEBUG is passed to the
linker to generate debug symbols, however, it caused the
identical COMDAT folding be disabled. We now pass /OPT:ICF
to the linker explicitly to prevent this.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=msvc-160
Change-Id: I02099edb81034ace7bb19f1164d57829e3979a5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to handle the possibility of versioned dep (Qt6::Foo).
Change-Id: I66797dbc59f00500892958e9c99c4555cddcb980
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If not, the resulting dep would end up as 'Foo>', but we need 'Foo'.
Change-Id: I246b66eb0ac6b076eea200c4d1ad84bba8ed179c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
*Not* using /permissive- exposes Qt and client apps to interesting
bugs and/or build failures, (e.g. QTBUG-87225, or
19b5520abf). We demand strict
conformance by any other compiler, it's time to demand it from
MSVC too.
The Windows headers themselves are clean starting from the
Windows Fall Creators SDK (10.0.16299.0), and moreover Qt 6 will
drop WinRT; therefore, the comment in the mkspecs does not apply
any more.
Since /permissive- implies /Zc:referenceBinding, drop that
option. The other implied options are set on MSVC < 2017,
but I leave them in to avoid tinkering with the fragile lists
of C/C++ flags.
Rename the CMake internal helper function to better describe
what it does.
Fixes: QTBUG-85633
Fixes: QTBUG-85637
Fixes: QTBUG-85635
Fixes: QTBUG-88244
Change-Id: Ie03fddb61aa066fdc14b7231c22e7108b4a02fbb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In the qmake-based build, the hostdatadir is the directory where "Data
used by qmake" is located. In the CMake build the equivalent is
INSTALL_MKSPECSDIR. Create the mapping accordingly.
Fixes: QTBUG-88211
Change-Id: I9e3d1af24bc7f41333ef2269fced5ab3fcfa848d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, QtDocsHelpers.cmake was invoking CMake to copy
files or directories instead of using installation targets.
This resulted in DESTDIR being ignored.
Now we create installation targets and ask CMake to
install them.
Change-Id: Idbc79d47a37f9ca865d28543bdbbdde3ba448fa3
Fixes: QTBUG-87382
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extend qt_configure_get_padded_string to make the feature list look like
qmake's.
Fixes: QTBUG-88144
Change-Id: I714f2b2f3537b506365a03b5b6bc3413e9cab167
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For now, we only support building Qt with the Ninja generator (and
Ninja Multi-Config).
Issue a warning when a different generator is used.
Allow opting out of the warning by passing
-DQT_SILENCE_CMAKE_GENERATOR_WARNING=ON.
Change-Id: I5faa5b0ca5fd42efc090ad2ccf4f896bd77e50ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In configure we need to set the Release configuration first to make it
the main configuration.
Change-Id: I5fe744b0dcea009c4d672bf519b38c80c87475dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In multi-config builds (which equals the debug-and-release feature) we
exclude tools of the non-main configurations from the default build.
But we still create installation rules for them. Mark those as optional
to avoid "cmake --install" yielding errors if those tools weren't built.
Fixes: QTBUG-85411
Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make zstd config based lookup quiet and check for version variable
as required for ZSTD target.
Add IMPORTED_LOCATION by default for pkg-config based search.
Expect that select_library_configurations will set correct value
for ZSTD_LIBRARY.
Fixes: QTBUG-88091
Change-Id: Ia5079154ce4fc4eefbc0931317219b5ca0f3f82f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Modify pro2cmake converter to add extra argument to
qt_internal_add_plugin. DEFINE_IF FALSE is added to generic plugins
those had "PLUGIN_EXTENDS = - " specified in .pro files.
Fixes: QTBUG-87861
Change-Id: I9269df19a32a088f5261f50e7ffff6d29c3d605f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.foo.module entry is used for linkage, so we shouldn't
add it for header only modules.
Change-Id: Ibb6e7ab08083ccab11d7e060f35c54153e3751c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For non-cross-builds, qt-configure-module is located in
CMAKE_INSTALL_PREFIX/bin, not below the staging prefix.
Fixes: QTBUG-88262
Change-Id: Ib6cdd88ece391d5b8ce850b991564e5bed1e475d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the user turns on debug_and_release with the configure script,
FEATURE_debug_and_release will not be set, and the debug postfix won't
be set correctly.
Directly use FEATURE_debug_and_release's condition instead.
Change-Id: Ica4af3caa25f2e6712eca4659818aac2c8b95256
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Configure now translates -developer-build to INPUT_developer_build
without setting FEATURE_developer_build.
The install prefix determination code in QtSetup.cmake happens much
earlier than the feature evaluation. As the developer_build feature is
merely a switch that's supposed to be flipped by the user, we can just
translate the INPUT_developer_build value to FEATURE_developer_build in
QtSetup.cmake.
Fixes: QTBUG-88318
Change-Id: I57918232359e2e367e41b779d3f4737731dd76e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Trying to locate zstd package configuration prior to use pkg-config.
Define explicit IMPORTED_LOCATION_DEBUG and IMPORTED_LOCATION_RELEASE
in case of pkg-config usage.
Fixes: QTBUG-88091
Change-Id: I3cb86a66fad4e7b78b3d2fcff061508fc25e25a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use select_library_configurations to select applicable libraries
set for PCRE2.
Fixes: QTBUG-88092
Change-Id: I11e669a0142d53a3c344c86bd1d8eb797df4ba97
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some repos (like qtimageformats) might not have Qt modules, but they
still need a target to pass to qt_internal_add_docs().
Allow passing custom targets to qt_internal_add_docs() without trying
to generate bogus include paths.
Change-Id: I12191e5b16c082e62e40c96d0eb4d6c0256e7ea4
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
"ninja install_docs" should not run the "docs" target, because with
the usual workflow
ninja docs
ninja install_docs
the documentation would be built twice.
That of course means that "ninja install_docs" will fail if "ninja
docs" wasn't run before.
Analogous for html_docs, qch_docs, the repository-level and
module-level documentation targets.
Change-Id: I8ad83602dd393b5afc79a19ab3d395987c889d0d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The following targets did not do any actual installation:
install_docs, install_html_docs, install_qch_docs,
plus their repository-level counterparts.
Add the following dependencies:
install_html_docs
--> install_html_docs_<repo>
--> install_html_docs_<module>
Analogous for qch.
The install_docs target already triggers install_html_docs and
install_qch_docs. Analogous for install_docs_<repo>.
Fixes: QTBUG-86738
Change-Id: I3468e000e050e2787a859e61d40161f5459cb351
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tools and library DLLs already have version information embedded.
Add the missing _qt_internal_generate_win32_rc_file call for plugins.
Fixes: QTBUG-87747
Change-Id: I619948f4066ce229d41e8b93f125751e1d28e26c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
INPUT_ variables enable FEATURE_ variable only in case if valid
"true"-like value is assigned from command line.
Amends dc43061e9a
Fixes: QTBUG-87755
Task-number: QTBUG-88142
Change-Id: I65e85c7548981fdec94366b531f6df6396be71b7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We have some cache variables that are used in our qt.toolchain.cmake
toolchain file, for example QT_CHAINLOAD_TOOLCHAIN_FILE. When CMake
runs a configure test with try_compile, our toolchain file is included
again, but only a restricted set of variables is available.
Add the variables that are used in our internal toolchain file to
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES. This makes them visible for
try_compile calls operating on source files.
Also pass the variables via the environment to support try_compile
calls that operate on whole projects.
Fixes: QTBUG-87873
Change-Id: Iebca9e23686bec5072194b15482e1782b9367a0e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were omitted in the original change, which cause cmake builds to
fail configuring
Change-Id: I37996099aaa0d912ce06b1f06c175cc5cf159e33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This matches how it is in the qmake mkspec, silencing a lot of
warnings - but contrary to when building with qmake, it's only
applied when building Qt itself. For external projects built with
cmake, the Qt headers are included with -isystem, which silences any
warnings from those headers.
Change-Id: I1a498d3c2715cb73e647668cb7226ceeffb7ff0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now all shared libraries and executables will get .debug files on
the platforms that support FEATURE_separate_debug_info
With the directory property _qt_skip_separate_debug_info certain
targets can retain the debug symbols in the binary e.g. lupdate with
MinGW 8.1.0 will cause objcopy / strip to fail.
Fixes: QTBUG-87015
Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
"configure" script translates feature-related parameters to INPUT_
variables instead of FEATURE_.
Both INPUT_ and FEATURE_ variables passed to cmake script are
equivalent. FEATURE_ has higher priority in case if both are defined.
Fixes: QTBUG-87755
Change-Id: If697a0d62ab839877a3196ea74e631582a570dda
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must write config.opt in the same directory we're reading it from.
We must not write the -top-level argument to config.opt.
This amends commit 2a29426e39.
Change-Id: I96da9094579fec29c290411677d6b538878399f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a new function that returns the minimum CMake version required to
build Qt. Pass that value to cmake_minimum_required() when building
qtbase and its standalone tests.
The minimum supported CMake version is read from qtbase/.cmake.conf
and its value should be updated when the need arises. It's the main
source of truth for all repos.
Provide a way to lower the minimum CMake version at configure time by
passing a value via QT_FORCE_MIN_CMAKE_VERSION.
This is not an officially supported way of building Qt. If the
specified version is lower than Qt's supported minimum, show a
warning.
Nevertheless the option is useful for testing how Qt builds with a
different minimum CMake version due to different policies being
enabled by default.
Issue warnings for CMake versions that are higher than the minimum
version but are known to cause issues when building Qt.
A counterpart change is needed in qt5 to ensure the minimum CMake
version is set at the proper time for top-level builds.
Ideally we would use the same 'check the CMake minimum version` code
in all our repositories, but that will cause lots of duplication because
we can't really find_package() the code and doing something like
include(../qtbase/foo.cmake) hardcodes assumptions about repo
locations.
So for now we don't bump the minimum version in child repo
cmake_minimum_required calls (qtsvg, qtdeclarative, etc).
Instead we record both the minimum supported version and the computed
minimum version (in case a different version was forced) in
QtBuildInternalsExtra.cmake.
Then we require qtbase's computed min version in
qt_build_repo_begin().
This won't set policies as cmake_minimum_required would, but at least
it propagates what minimum CMake version should be used for child
repos.
We might still have to bump the versions in child repos at some point.
Task-number: QTBUG-88086
Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The flags go before the library in the final linker line, as opposed
to the dependencies declared in LIBS.
This allows us to declare the flags for the entrypoint
in the project file of the entrypoint, instead of in
a standalone prf.
Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On the qmake-side we had exports, but they were quoted.
Change-Id: I95af4b927079691cab6403fec850f345ba181a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The arguments -platform, -xplatform and -device determine the mkspec
that's used for the qmake companion files.
If the user specifies a mkspec that indicates usage of clang or icc,
set the respective CMake variables to use one of those compilers.
Fixes: QTBUG-87836
Change-Id: I2b10d819b0eb92a97d7f79672547b1e2d821cf33
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>
1. clang-cl doesn't support "-fno-exceptions", it uses msvc's parameter.
2. some parameters supported by msvc are not supported by clang-cl
and they are causing huge warning message flood, don't add them.
3. use correct optimize parameter for clang-cl.
Change-Id: Idbadf139127143c5fa6c49068588cb26f47da7a2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When linking static libraries, MSVC's link.exe complains about
the unknown parameter "/INCREMENTAL:NO" and output a lot of warning
messages about this. This doesn't happen when it's linking exes
or dlls.
The situation is a lot more worse when we are using clang-cl.
clang-cl will print some error message like it can't find a
file named "/INCREMENTAL:NO" and just stop compiling. It seems
clang-cl treat unknown parameters as input files.
Fixes: QTBUG-87875
Change-Id: I37ed29de082b0258e81494db54f275417ab42708
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.<module>.DEFINES assignment in pri files needs to take into
account the module name when computing the define name. This is the
MODULE value that qmake specifies.
In CMake that would be the value of CONFIG_MODULE_NAME.
Previously the value of the define was computed in
qt_internal_module_info() without taking into account the module name.
While qt_internal_module_info() ended being used also for plugins and
other target types, the defines computed by it were meant to be used
only for Qt modules.
Thus remove the <result>_define assignment from
qt_internal_module_info and move its computation directly into
qt_internal_add_module, taking into account the value of
CONFIG_MODULE_NAME.
The only other use of module_define was in qt_internal_add_plugin but
that was merely a long overdue copy-paste error, qmake doesn't
propagate QT_FOO_LIB defines for plugins.
As result, a define special case in testlib is not needed anymore,
because the define is now computed properly.
Finally, QT_FOO_LIB should not be used while building the Qt module
itself, so instead of using PUBLIC_DEFINES option of
qt_internal_extend_target, use target_compile_definitions(INTERFACE)
directly.
Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Makes the diff between Qt 5.15 and 6.0 easier to read, to see what's
missing.
Change-Id: Idf8aa17b3ab8494f6855c172665423a53ca8a024
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We do not have host-specific INSTALL_*DIR variables in the CMake build.
It is equivalent to a qmake build with host prefix = prefix.
Change-Id: I65731e6038508b6c28e3f2819b624ba19abfc82a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value of this variable must be exactly "mkspecs" or end with
"/mkspecs".
Change-Id: I39f83e9660794dfe23f5fd39fb1084b87ba1f140
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value of this variable - whithout the mkspecs part - is what's
called the host data dir in Qt5.
Fixes: QTBUG-87681
Change-Id: I3dfeed17e8a614476aef4d9c651a141ce62e6551
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must escape backslashes in CMake code that's to be evaluated and in
the arguments we read from config.opt.
Change-Id: I65d033c77f71888974983aa3d834acb2fe89f3fb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent change we will call another CMake script from
qt-configure-module.bat. Write the location of qtbase/cmake into the
generated scripts instead of the path to QtProcessConfigureArgs.cmake.
Change-Id: Ie333b16d310b215c6e49efa27740c7525453d28f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake considers ON/OFF as booly string values regardless of the case.
Make the value comparison in QtFeature.cmake case-independent.
It's now possible to build Qt with '-DFEATURE_gui=off'.
Fixes: QTBUG-87948
Change-Id: I3d948e8219ad9728414803c8c4cd756034073b46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
Previously we determined if a library represented by an absolute path
is a Qt module by checking if it's located in the build dir of the
current repo.
That is not sufficient for non-qtbase prefix builds, where
a Qt module might link against both a module in the current
build dir and in the prefix dir.
Detect such cases, and rewrite the absolute paths to relocatable paths
(either framework flags or paths starting with $$[QT_INSTALL_LIBS].
This should fix building examples with qmake that use QtQuick.
Fixes: QTBUG-87840
Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an EXTRA_CMAKE_FILES argument to qt_internal_add_tool()
that allows tools to install an additional Macro.cmake file.
This is modelled after similar functionality in qt_internal_add_module.
Task-number: QTBUG-87870
Change-Id: I80838b8966f1018fdd379b1da877b6bc418de075
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fixes a regression introduced in commit 748b3b9c89 for builds
that are both not a QT_SUPERBUILD and not QT_WILL_INSTALL.
Change-Id: I52b920176a2696fa6206b89b2b69ae1a7f3fbc25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The top-level prepare_docs target is supposed to run before the
generate_docs target.
The repository-level targets like prepare_docs_qtbase now also run
before their respective generate targets.
To achieve that, several intermediate targets had to be introduced.
The dependencies for top-level generate_docs look like this:
/--> generate_top_level_docs_Core --\
generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs
\--> ... --/
The dependencies for repo-level generate_docs_<repo> look like this:
/--> generate_repo_docs_Core
generate_docs_qtbase ---> generate_repo_docs_Gui
\--> ...
generate_repo_docs_Core --\
generate_repo_docs_Gui -----> prepare_docs_qtbase
... --/
Analoguous for qch_docs.
And last but not least, the module-level generate_docs_<module> depends
on prepare_docs_<module>, just like before.
The strangely named top-level install targets have been renamed to
install_html_docs, install_qch_docs and install_docs.
The html_docs target is now merely an alias for generate_docs.
Apart from prepare_docs, the top-level targets do not depend on the
repository-level targets anymore. Targets that are just an alias (docs,
install_docs, ...) have been re-defined to depend just on the respective
top-level targets.
Fixes: QTBUG-87758
Change-Id: I24466d3a252d518a30a2064bf876be881c46231f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value is useful for QPA plugins built in repos other than qtbase,
to decide if it should be a default plugin or not.
Currently useful for qtwayland.
Also export a qmake value assignment when doing static builds, just
like src/gui/configure.pri does.
Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Otherwise we get error messages from CMake.
Change-Id: I374b87e38550062b841b7eacf5fbb6bb5ccbdbde
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow CMake for Android to use ANDROID_NDK_ROOT to deduce the path for
QT_CHAINLOAD_TOOLCHAIN_FILE instead of the user providing it manually.
Change-Id: Ida728011d5ca8d5a723d341ea77b173e8f105f8c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is meant to be called by our CI instructions to build standalone
tests of a Qt repository.
Currently it just calls qt-cmake with
-DQT_BUILD_STANDALONE_TESTS=ON, but it might contain more things in
the future.
The script also simplifies configuring standalone tests locally, due
to not having to remember the name of the magical variable.
Change our CI instructions to use the new script.
Change-Id: I6bc02b4e94adc9d0d05fecb0fe70a561043271f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
With the introduction of the new 'default_qpa_plugins' custom target,
a target dependency cycle occurred in qtwayland:
qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin ->
WaylandClient -> qtwaylandscanner
The issue is twofold:
- default_qpa_plugins accidentally depended on non-qpa plugins.
- All qpa plugins were enabled by default, including the wayland ones.
Fix the default_qpa_plugins target not to depend on regular non-qpa
plugins.
Also fix qpa plugins not to be enabled by default, but instead only
choose one qpa plugin to be the default (via evaluating the
DEFAULT_IF) condition.
Amends df9c7456d1
Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The way we detected whether SysrootifyPrefix needs to be set was
incorrect.
We checked if extprefix == prefix => SysrootifyPrefix should be
true. But that was previously always the case for a non-prefix build,
which means it was not possible to build apps (due to qmake expecting
to find include dirs in the sysroot, despite the non-prefix Qt not
being installed anywhere into the sysroot).
Instead we should do what qmake does. Only set SysrootifyPrefix to
true if extprefix was not provided and a sysroot is available.
To make it work for iOS and Android, the sysroot detection code had to
be moved earlier than the SysrootifyPrefix detection.
Task-number: QTBUG-86053
Change-Id: Idcc1260a675fb2ef9ae27fc9dc42a68b30f763b8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The html_docs target does not need to call QDoc a third time as
both its dependencies already do that.
With qmake, html_docs did invoke QDoc if CONFIG did not include
'prepare_docs', but none of the Qt modules used that configuration.
We can manage without it for now.
Fixes: QTBUG-87751
Change-Id: I45d2d06006c566c431ae41d7f3a06d6b809987f2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For top-level builds it's desirable to have "ninja generate_docs" build
all tools needed to generate the documentation.
This is problematic since the doc-generating targets are created before
the doc tool targets. Thus, we must defer the dependency connection if
the doc tool target is not yet available.
This patch adds the functions qt_internal_defer_dependency and
qt_internal_add_deferred_dependencies.
Change-Id: Ica940b80882e67cb0e0943e95541f7f4d1885948
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of propagating the deprecation wranings, we compiled all code
with -Ddeprecations.
Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
qmake treats internal modules as just the regular module file,
but with a _private suffix, as opposed to the current cmake
logic, that treats it as the private module file, resulting
in missing e.g. the Qt.foo.module entry.
Change-Id: Id55ca4c23921656d5abfd1d0fdf6430d4fe120bf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch allows in top-level prefix builds to build Qt and to generate
the documentation without running cmake --install first.
For top-level builds we now always use the qdoc binary from the build
directory, not the installation directory.
We also have to copy the global doc files to the build directory to make
them accessible to the generate_docs target.
Change-Id: I2251603418fc3df9a21c7f2892789e9ff6c8cc21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's not sufficient to pass -I{prefix}/include when doing the header
clean check.
We need to propagate all target include directories and compile
definitions, and also the compile flags for good measure.
For macOS frameworks we also need to explicitly pass an -iframework
flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style
includes are found when building other repos than qtbase.
Task-number: QTBUG-82615
Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This ensures ccache or sccache is used to cache the compilation of the
headerclean checks.
Task-number: QTBUG-82615
Change-Id: Ie944eb1d643e7271551c9f8337609741e419e9d8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It appears there's a difference between the chosen macOS compiler path
in the CI versus the compiler path on my local machine.
In the CI the chosen compiler path ends up 'being /usr/bin/clang++'
whereas for me locally it's
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
For some reason the headersclean commands succeed in the CI, but
locally they fail for me saying that standard library includes can not
be found, unless an explicit sysroot flag is specified.
I assume that in the CI the '/usr/bin/clang++' compiler shim chooses some
implcit sysroot, whereas the longer Xcode compiler expects an explicit
sysroot.
It's probably also affected by the fact that in the CI we pass an
explicit CMAKE_OSX_SYSROOT to a non-standard Xcode location e.g.
/Applications/Xcode11.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
Note the '11' in the Xcode app name.
Locally I don't pass a custom CMAKE_OSX_SYSROOT, and my Xcode is
installed in a regular location e.g /Applications/Xcode.app.
The sysroot flag and path is added to regular CXX compilation rules
inside CMake's core (in cmLocalGenerator.cxx).
Reuse the same variables that CMake uses and add them to our headersclean
command rules.
Task-number: QTBUG-82615
Change-Id: Ic03ea27e39471f5fa168eb5970bf3d3f1d1be251
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add 3 new convenience custom targets:
'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'.
Additionally, if we detect that an internal executable / test
links against Gui, add a dependency on the 'qpa_default_plugins'
custom target, so that if a developer configures Qt for the first time
and then calls ninja 'tst_foo_check', we ensure the test will launch
successfully because the default QPA plugin will also be built.
Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For example, we must not prepend -l to -pthread, -framework and -lfoo.
Fixes: QTBUG-87760
Change-Id: Ie1bc7a76183c2c4980c519b5f23dde6c47ec85a9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...instead of qt-cmake-private.
Also, add ".bat" on Windows.
Change-Id: I2aa94ac76f2dadfb8e94d68b19bb379b3d45a93d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The variable to check for a Windows host system was mis-typed.
Change-Id: I25b14b80d25bfec0c1a00e99833520b6fb6a4b02
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This makes the diff-ing of the config summary between qmake and CMake
builds correct.
Change-Id: I720b69572c23afd78e6d0bea6cdf0740980c3b36
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
In configure.json files we have inputs with dashes, e.g.
bundlex-xcb-xinput. In configure.cmake files, these are read in their
normalized form, e.g. INPUT_bundled_xcb_xinput.
Normalize the input names in QtProcessConfigureArgs.cmake like we
already do for feature names.
Change-Id: Iece414d40a0e9e2920580f2fda68e25cd32674c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On a mac that can build all of Qt with CMake, Ninja, and command line tools,
there should be no warning just because a build tool that
won't get used is not available.
Turn the warning into an informative message instead so that IDE
integrations (such as VSCode's CMake integration) don't flag warnings.
Change-Id: I250c0e5dd0633b36ff2b690a52ba7ce3ceb22218
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING.
qt_internal_export_additional_targets_file now gets two lists of target
names when run from qt_export_tools:
- TARGETS containing actually existing targets, and
- TARGET_EXPORT_NAMES containing the target names as they appear in the
additional target info file.
Operations that require actual targets are run on the TARGETS, in the
additional target info file only TARGET_EXPORT_NAMES are written.
This distinction is required for the case where the host Qt lacks a
tool that is built in the target Qt.
Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built
with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built
in the target Qt. TARGETS contains qmljs_native, and
TARGET_EXPORT_NAMES contains qmljs.
Fixes: QTBUG-87693
Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Do not append "/qtbase" to QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX
when doing a top-level build. The "/qtbase" suffix is already part of
this variable's content.
Fixes: QTBUG-87682
Change-Id: If1c2075dc58d4b07a4c3a1eed12cc3336c5dc8e6
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not print warnings for the configure arguments -commercial,
-opensource and -confirm-license. We're not removing the arguments yet
to keep existing build scripts working.
Fixes: QTBUG-86096
Change-Id: Ieb63e2f2b81c022e8559cde6c3e0be0b8ce655ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The use-case is relevant for other platforms as well.
Now that Qt has a module system we can also replace a lot of the
hand crafted logic for linking with simpler constructs.
Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some of them have a different (hopefully better) name now.
Some are marked as Technical Preview.
Some are renamed to be internal.
Marking add_qt_gui_executable as TP with the intention to un-TP it
after we rename it and change its behavior as discussed in the API
review meeting.
Additional changes to add_qt_gui_executable and qt6_add_resources have
been filed as separate tasks that will be worked on separately.
See comments on PS1 for details.
Task-number: QTBUG-86827
Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The Android toolchain file is now autodetected from the location of the
NDK. The NDK location can be specified by setting the CMake variable
ANDROID_NDK_ROOT. Auto-detection of the Android toolchain file is the
only purpose of this variable.
In recent Android SDK installations the path to the NDK is well-known
and can be auto-detected too. If only ANDROID_SDK_ROOT is given, we try
to detect ANDROID_NDK_ROOT first and from that the Android toolchain
file.
Adjust the build instructions in cmake/README.md, and remove the part
where we suggest to set some environment variables that are only used to
create the cmake call.
Task-number: QTBUG-87068
Change-Id: Ia0df5df7651e98979e9cead1cdae7b17ecbc4afb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want this in order to be able to export constexpr members.
Change-Id: I33ba7964ebee54fe656df983985d8d6fa0b99358
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This needs to map to ECM_ENABLE_SANITIZERS.
Fixes: QTBUG-87316
Change-Id: I9e983728af0ba69fd428944e647f0afae8c61772
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Provide two customization points:
- optionally include a 'qt.toolchain.extra.cmake' file if it exists
and is placed next to the main generated toolchain file.
This use case is mostly for the Qt installer, so that it can create
an extra file with correct installer-provided paths, instead of
patching the toolchain file directly.
- optionally include a file passed via the command line CMake argument
'QT_TOOLCHAIN_INCLUDE_FILE'.
The use case is for application developers that might want to adjust
the toolchain file after the modifications done by the Qt installer.
These options do not replace the existing QT_CHAINLOAD_TOOLCHAIN_FILE
option, which is meant to chainload a platform specific existing
toolchain file (like Android or Emscripten).
Task-number: QTBUG-87068
Change-Id: I956949840f55742cfbd3bc8fc0bd8c6b3f774d3d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
And wrap the various behaviors into separate functions.
Change-Id: If940351af34e445de050f2b46301de7080b1555b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Detect an iOS build when either an -sdk option is passed
or when -xplatform macx-ios-clang is passed as a target
mkspec.
Now that CMake 3.17 is released, change the default behavior of the
iOS build to configure with simulator_and_device set to ON, like it
is with qmake.
Update the documentation regarding iOS configuration.
Change-Id: I91aaf706610b8d3c69f1ad4ba9dadee2b1e5db97
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It appears that CMake's Xcode generator default behavior can't really
handle imported object libraries location, which Qt uses extensively
(all the qt_add_resource calls).
Specifically the project fails to configure with the following error
message:
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures.
An issue was filed upstream at
https://gitlab.kitware.com/cmake/cmake/-/issues/21276
In the mean time, it looks like it's possible to work around the issue
by setting XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property to OFF.
This needs to be done before the very first project() call, so we do
it in the generated Qt toolchain file.
Note that the workaround only works if the CMake project is configured
with a single architecture given to CMAKE_OSX_ARCHITECTURES.
If multiple arches are given, it will fail with the same error
message.
Fixes: QTBUG-87198
Change-Id: I2556ae28b2fc2d9cfe464a5acf9c4fcbaf01b654
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
