For AUTOMOC, we were missing the compiler flavor flag, as well as the
WIN32 define. While the latter has not caused any known issues yet, the
former is rather problematic for implementing __has_include in moc.
Note that this only applies in the case where the AUTOMOC flags are set
by us in a qt_ function like qt_add_excutable. Plain add_executable
won't benefit from it, but we already mention that Qt targets should not
use plain CMake functions.
This change is (indirectly) tested by the commit adding __has_include
support for moc.
Task-number: QTBUG-136097
Pick-to: 6.10 6.9 6.8
Change-Id: Ie2beb08a44a3a67e3bc363d9c1ba93b7d6a49133
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sync the cmake arguments to search for DB2 with the rest of the qsql
find modules and provide a DB2_ROOT env or cmake var.
Also allow the old variables as a fallback.
Pick-to: 6.10
Change-Id: I587e519b5cf3513e9580f64f0fb9b46bf789da5c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function append the unique entries to the CMAKE_CONFIGURE_DEPENDS
property. This suppress the ninja recompat issue, which complains
about the duplicated entries in that come from the
CMAKE_CONFIGURE_DEPENDS property. It's likely the CMake issue, but
we may work around it.
Pick-to: 6.8 6.9 6.10
Change-Id: I2f10834b0dca3d2aa08fe13fba69849e97fa77d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's no longer available on macOS 26, and we don't use it anymore
anyways.
Pick-to: 6.10 6.9 6.8 6.5
Change-Id: Ia1d0e37dda177f333646e598e517f4af20215dad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously QT_CMAKE_EXPORT_NAMESPACE was set by calling
find_package(QtBuildInternals) at repo dir scope, even in a top-level
build.
Starting with ddcafa0a51c65d86f6b5481f06fce5faeb75920d in
qtdeclarative, we now have a deferred call of
_qt_internal_write_deferred_qmlls_build_ini_file in the
CMAKE_BINARY_DIR scope, which lacks the QT_CMAKE_EXPORT_NAMESPACE
variable.
This caused errors in a top-level standalone tests build:
Error evaluating generator expression $
No target "::qtpaths"
CMakeLists.txt:DEFERRED
To avoid the error we now set QT_CMAKE_EXPORT_NAMESPACE in the
top level scope.
To avoid duplicating the code into the QtBaseTopLevelHelpers,
we extract the qt_internal_top_level_setup_cmake_and_export_namespace
function into a new QtBuildInternalsHelpers.cmake file, which is
included by both QtBaseTopLevelHelpers.cmake and
QtBuildInternalsConfig.cmake.
We also copy and install that file.
This has less side effects than trying to call
find_package(QtBuildInternals) in the top-level scope.
Pick-to: 6.10
Change-Id: I8e54e21d3f07ee86860cad49d6e43e0fdefbcee3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We didn't copy the standalone test template files into the build dir
when configuring a prefix build.
We also need to copy the mkspecs.
Pick-to: 6.8 6.9 6.10
Change-Id: I517165b2b8db84b0766935e3d535a7a1ef2b6ad9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Starting with 605913f9d7a60461939c1a8fb8dac05054cade2d we run
configure.cmake compile tests lazily during feature evaluation.
This means that qt_config_compile_test() calls will no longer set
TEST_foo_OUTPUT variables in the scope of configure.cmake files and
thus the build output of compile tests is no longer available for
configure summary error reports.
Instead of setting the output variable in the caller scope, save the
output in a global property.
Then, when we add error reports that mention compile tests either in
CONDITION or in a newly introduced COMPILE_TESTS_TO_SHOW_ON_ERROR
option, dump those outputs in the error report.
We continue to set the output in the parent scope, in case if
qt_run_config_compile_test is called manually.
Amends 3334a77ecfb792fba0144e99887f11cd0fa2506d
Amends 605913f9d7a60461939c1a8fb8dac05054cade2d
Pick-to: 6.8 6.9 6.10
Fixes: QTBUG-137198
Change-Id: Idc0470556a053123286983c44063e17b7eb9949d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Capture the output of the check_cxx_source_compiles calls in
qt_internal_add_link_flags_no_undefined like we do for
qt_config_compile_test.
Amends 3334a77ecfb792fba0144e99887f11cd0fa2506d
Pick-to: 6.8 6.9 6.10
Task-number: QTBUG-137198
Change-Id: Ic7dd4eae0ac1af0f8293f2ce285d2987e4e26249
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Emit a warning if `FEATURE_*` variable is set. The "feature" is not
registered as a true feature after deprecation.
Pick-to: 6.10 6.9 6.8
Change-Id: I715af231c228c73d70b037ee31aa61edcd45c21e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
One can now run "ninja android_docs" to generate HTML docs for Android
Java sources of Qt. This is done with javadoc.
One can now run "ninja android_source_jars" to generate source jars for
Android. They're supposed to be loaded into an IDE.
The targets are enabled automatically for Android builds.
For non-Android builds, set QT_BUILD_HOST_JAVA_DOCS=ON to create those
targets. In that case you must also set ANDROID_SDK_ROOT.
Fixes: QTBUG-117028
Change-Id: I2df51153359a95870c055d3ee373b8381f10cb51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
iOS prl files for static frameworks were previously placed at a path
like
6.8.3/ios/lib/QtCore.framework/Versions/A/Resources/QtCore.prl
This caused qmake to silently fail to find iOS framework prl files.
The failure could only be seen when calling qmake with -d -d:
DEBUG 2: QMakeMetaInfo: Cannot find info file for
6.8.3/ios/lib/QtCore.framework/Resources/QtCore.prl
This in turn can lead to various build failures if a different non-iOS
prl file is found in a system path.
Place the prl file into the root of each framework, e.g. at
6.8.3/ios/lib/QtCore.framework/QtCore.prl
We didn't have this issue in 6.7 and earlier, because by default iOS
was built with static libraries rather than static frameworks.
Amends 291817b0bf3f351843b0c1d0de237dc8df5c0fa5
Pick-to: 6.8 6.9 6.10
Fixes: QTBUG-137297
Change-Id: Idff8e808e9bfc009f82d2a59e5e6752ed8a55714
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If CMAKE_OSX_SYSROOT or QT_APPLE_SDK was set, we still reported the
default platform sdk path, rather than taking into account the set
value.
Improve the reporting by considering these values.
The implementation is incomplete because we don't handle explicit sdk
paths, but this is not critical for the current use cases, because the
value of the function is only used for reporting purposes.
Amends ab7eb492cba64fe985ea80b2f0be22c1c18f3c5e
Pick-to: 6.8 6.9 6.10
Change-Id: Ic69aec3641d435736018c96f72ba7f75a0f74508
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Normally `INSTALL_DATADIR` is the canonical place for
`share`/`CMAKE_INSTALL_DATADIR`, but this standard is not well
enforced.
In 834d92a, `INSTALL_SHAREDIR` was introduced to better enforce this
standard and allow to install into third-party program's
`CMAKE_INSTALL_DATADIR` (e.g. wayland). This ended up being used as
`INSTALL_SHAREDIR/qt6` instead, but this leaves little room for
configuration and renaming.
This change introduces a namespaced variant that is guaranteed to be
owned by Qt.
Pick-to: 6.10
Change-Id: I25c0e5b47c402b178120e9e628fdfaf4aaad27ad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function sets properties on target that then are propagated
transitively. This only works with Qt modules, but can be extended
for other Qt targets later. These transitive properties not necessarly
require Qt be built using CMake versions supporting transitive
properties(>= 3.30). Properties are stored and exported within the
Qt module unconditionally and can be used in user projects, if
CMake version allows this.
Change-Id: I1ff6f1099753784c721dc1e3cd972dcd9dafedc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This file sets the transitive module properties provided by
Qt Module that is built using CMake versions < 3.30. The idea
is to not limit user projects capabilities and allow using
transitive Qt Module properties if user CMake version allows it.
If Qt Modules are built using CMake versions >= 3.30 this code is noop,
since values are stored directly in the respective
INTERFACE_properties.
Change-Id: I5a0bc0aa4f79a04c81dfa0fee1d37cfee5935b0f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This changes the error message I get when configuring with
-DFEATURE_sanitize_thread=ON from:
CMake Error at cmake/QtFlagHandlingHelpers.cmake:183 (message):
Platform linker doesn't support erroring upon encountering undefined
symbols. Target:"Core".
Call Stack (most recent call first):
cmake/QtModuleHelpers.cmake:898 (qt_internal_add_link_flags_no_undefined)
src/corelib/CMakeLists.txt:30 (qt_internal_add_module)
to:
ERROR: detected a std::atomic implementation that fails for function pointers. Please apply the patch corresponding to your Standard Library vendor, found in qtbase/config.tests/atomicfptr
CMake Error at cmake/QtBuildInformation.cmake:240 (message):
Check the configuration messages for an error that has occurred.
Call Stack (most recent call first):
cmake/QtBuildInformation.cmake:59 (qt_configure_print_summary)
cmake/QtBuildRepoHelpers.cmake:393 (qt_print_feature_summary)
cmake/QtBaseHelpers.cmake:287 (qt_build_repo_end)
CMakeLists.txt:36 (qt_internal_qtbase_build_repo)
Pick-to: 6.8 6.9
Change-Id: If6243362521802d8b1348ae53d744c33add814f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 731d9a13956ef40e3f563f5ff5ff5c250b8d6d94.
Reason for revert: ${pcfiledir} cannot be used, because this
leads to wrong prefix values if PKG_CONFIG_SYSROOT_DIR is set.
See the comments of the associated task for instances of this
problem in other projects.
Pick-to: 6.8 6.9
Task-number: QTBUG-136210
Change-Id: I2a60946828f07866b931dacfe0ef81346f1aac9d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We set the CMP0156 policy to NEW for Apple platforms for each created
Qt target, but the debug message is generic, so we should only show it
once.
Amends c20d7bcb86361d0c9f8af3807dcad9db1a3a5ca0
Pick-to: 6.8 6.9
Task-number: QTBUG-135978
Change-Id: I332bd357999647df1d5f715d154fb568911889b1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Currently qmltestrunner is built as a tool, instead of an app.
That means that for most cross-compiling platforms (aside from Yocto),
the build system will look for a host binary when referring to the
qmltestrunner target. We want to look for the target platform binary
instead.
Switch the code around to prefer looking for the target platform
binary via find_program, before falling back to referring to it by
target name.
In the future when we change qmltestrunner to be an app, and also
expose its target platform binary as a target name, this should not be
needed anymore, and we could rely solely on the target name.
Amends 9edcc4690665496c2b6f15876b3979487dbad22a
Task-number: COIN-1211
Task-number: QTBUG-137005
Change-Id: If2eb93d8832a17aae3d0648d1d0f5997805796fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If a developer configured Qt with
-DQT_GENERATE_SBOM=ON
-DQT_BUILD_TESTS=ON
-DQT_BUILD_TESTS_BY_DEFAULT=OFF
The would get the following error upon installation of qtmultimedia:
CMake Error at
qt_sbom/SPDXRef-PackagedFile-qt-plugin-MockMultimediaPlugin.cmake:5
(message):
Cannot find 'plugins/multimedia/libmockmultimediaplugin.a' to
compute its checksum.
This happens because QT_BUILD_TESTS_BY_DEFAULT == ON sets the
EXCLUDE_FROM_ALL directory property on the tests directory, which
means all plugins created under tests/ subdir are not installed by
default, and the SBOM code could not read the installed files to check
the checksums.
In such a case, set a QT_INTERNAL_TEST_TARGETS_EXCLUDE_FROM_ALL
directory-scoped variable in the tests/ subdir, and use that as a
marker for the sbom code to know it should skip the checksum check.
Pick-to: 6.8 6.9
Fixes: QTBUG-137168
Change-Id: I970c3bc5732cc648549e5099fa1d50b3b39cb26f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
...in _qt_internal_find_qt_dependencies. In the case where a package is
loaded via its own dependencies (Qt6FooPrivate -> Qt6Foo ->
Qt6FooPrivate) the inner _qt_internal_find_qt_dependencies call did
unset the backup value of QT_NO_PRIVATE_MODULE_WARNING. This could lead
to an unwanted display of the private module warning.
Treat the backup variable as a stack to deal with this situation.
Pick-to: 6.9
Change-Id: I0ee3700a040b0df8c6090470ea6fc515cb93a7d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test and example standalone builds should not install
the wayland files.
Change-Id: If313479c8e17325cc3761fea093368f14d484d74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When the additional path did not point to cmake path, the
loop was using non-existing variable.
Pick-to: 6.9 6.8
Change-Id: Ie9599231599c3b90125825414956e345634c85ef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use QT_ADDITIONAL_PACKAGES_PREFIX_PATH to look for qmltestrunner.
Needed if module install is using separate staging prefix, like is
done on Yocto builds.
Change-Id: Icfe972a7ab1d0c99518383eab1c885e490cdb4d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Backstory.
1) Starting with Qt 6.8, the prebuilt Qt for iOS SDK is built as
static framework bundles instead of static libraries. That is done so
that we can embed a privacy manifest into each framework bundle.
2) Up until CMake 3.28, CMake would not attempt to de-duplicate static
libraries (or frameworks) on the command line. Starting with CMake
3.29, the CMP0156 policy was introduced to allow such de-duplication.
3) Since a while ago, Qt had its own policy handling for CMP0156,
which it force sets to OLD, to disable any de-duplication. That was
done to avoid possible regressions on platforms where link order
matters.
4) A developer might add the -ObjC linker flag to a project, to ensure
the linker retains all Objective-C categories it encounters in all the
static libraries that were provided on the link line. Retaining in
this case means that the /whole/ object file of a static library will
be linked to the final executable.
5) The Apple ld linker (both the legacy and the new ld_prime one)
can't cope with duplicate static frameworks on the link line when the
-ObjC flag is used.
It ends up throwing duplicate symbol errors, from trying to link the
same object file from the same static framework more than once.
The linker works just fine if the link line contains duplicate static
libraries, rather than static frameworks.
6) When a project links against Qt6::Gui and Qt6::Core, the link line
will contain Qt6::Core twice. This gets even more involved, when
linking plugins, which cause static framework cycles, and thus a
framework might appear multiple times.
Thus, we have the situation that Qt forces the CMP0156 policy to OLD,
Qt6::Core appears multiple times on the link line, no de-duplication
is performed, the project adds the -ObjC flag, and the linker throws
duplicate symbol errors.
We can fix this by force setting the CMP0156 policy to NEW when
targeting Apple platforms and using CMake 3.29+.
A potential workaround for a project developer is to set the policy
to NEW manually in their project.
Unfortunately that doesn't work for older Qt versions.
That's because CMake applies the policy value when add_executable is
called, and the policy value in qt_add_executable is the one that is
recorded when the function is defined. And the recorded policy is
always OLD, because Qt6Config.cmake calls cmake_minimum_required with
VERSION up to 3.21, which resets the policy value to OLD.
So we have to force set the policy in qt_add_executable /
qt_add_library via the existing __qt_internal_set_cmp0156 function.
The __qt_internal_set_cmp0156 had some diagnostics to show a warning
when the user modifies the policy themselves, but this never worked
because of reason stated above: the policy value was always overridden
in Qt6Config.cmake.
To actually make the diagnostic work, there is now new code to save
the policy value in the current directory scope, before Qt resets
it.
This only works if a project uses the find_package(Qt6 COMPONENTS Foo)
signature. It won't work with a find_package(Qt6Core)-like signature.
The policy value is not modified for platforms other than Apple ones
for now.
Amends 9702c3c78b2c16db6a9d0515d7d7698d9b064cd8
Pick-to: 6.5 6.8 6.9
Fixes: QTBUG-135978
Change-Id: I4d6e6c2a01e7092b417fc669d2aea40cf2dca578
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The setup:
- build Qt with '-static -qt-zlib'
- configure a user project with plain cmake and -DQt6_DIR pointing to
the Qt6 package
In this case, the implicit find_dependency(BundledZlib) call will
fail with:
CMake Error at lib/cmake/Qt6/QtFindWrapHelper.cmake:120 (message):
Can't find Qt6::BundledZLIB.
Call Stack (most recent call first):
lib/cmake/Qt6/FindWrapZLIB.cmake:6 (qt_find_package_system_or_bundled)
cmake/share/cmake-3.31/Modules/CMakeFindDependencyMacro.cmake:76
(find_package)
lib/cmake/Qt6/QtPublicDependencyHelpers.cmake:36 (find_dependency)
lib/cmake/Qt6Core/Qt6CoreDependencies.cmake:39
(_qt_internal_find_third_party_dependencies)
lib/cmake/Qt6Core/Qt6CoreConfig.cmake:42 (include)
lib/cmake/Qt6/Qt6Config.cmake:233 (find_package)
CMakeLists.txt:7 (find_package)
For example it would fail for the rasterwindow example configured with:
cmake ~/qtbase/examples/gui/rasterwindow \
-DQt6_DIR=$HOME/builds/dev-mac-static/qtbase/lib/cmake/Qt6
The failure happens because we don't pass any additional paths to the
find_package call that looks for BundledZlib, as opposed to how we do
it for module packages.
The project configuration does not fail if it is configured with any
of the following variables:
- Qt6_ROOT or
- CMAKE_PREFIX_PATH or
- the Qt generated toolchain file.
That's because these implicitly add relevant paths where to look for
Qt packages.
This came up in qtdeclarative RunCMake CI tests, where we only pass
Qt6_DIR to the test projects. It didn't come up in qtbase, because
none of the current qtbase RunCMake tests try to find Qt6Core.
To fix this particular case, conditionally pass the same paths that
Qt6Config.cmake uses when looking for module packages, to the
find_package call that looks for the bundled target.
We do it conditionally for bundled targets only, because for system
libraries we want to default looking for the module
FindWrapSystemFoo.cmake files.
Add a RunCMake test which will try to find a few Qt modules solely
based on having only Qt6_DIR set.
Pick-to: 6.8 6.9
Change-Id: I4d4e548f4c10370c4964ab8968b5772e26855dd4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The code was missing an escaped dollar sign.
Pick-to: 6.8 6.9
Task-number: QTBUG-122899
Change-Id: I51bff0a128546085e9418682b540d92eacfdbbe4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add CMake variable to allow use of DESTDIR when installing examples
in a standalone example build and skipping the fake prefix that would
be otherwise used. Similar variable is already used for tests.
Pick-to: 6.9 6.8
Change-Id: I427cbb5c198f8e89b1685792b7c1d90413213254
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qtwayland repository has been filtered for commits relating
to the Wayland client, via the following git-filter-repo command:
git filter-repo --paths-from-file wayland-move.txt --force --refs HEAD
And then merged into the qtbase repository via
git merge --allow-unrelated-histories
The following git-filter-repo instructions have been used:
src/CMakeLists.txt
src/CMakeLists.txt==>src/platformsupport/wayland/CMakeLists.txt
src/configure.cmake
src/configure.cmake==>src/platformsupport/wayland/configure.cmake
src/client/Qt6WaylandClientMacros.cmake
src/client/Qt6WaylandClientMacros.cmake==>src/tools/qtwaylandscanner/Qt6WaylandClientMacros.cmake
src/compositor/Qt6WaylandCompositorMacros.cmake
src/compositor/Qt6WaylandCompositorMacros.cmake==>src/tools/qtwaylandscanner/Qt6WaylandCompositorMacros.cmake
src/3rdparty/
src/3rdparty/patches/==>src/3rdparty/wayland/patches/
src/3rdparty/protocol/ivi/REUSE.toml==>
src/3rdparty/protocol/ivi/ivi-application.xml==>
src/3rdparty/protocol/ivi/ivi-controller.xml==>
src/3rdparty/protocol/ivi/qt_attribution.json==>
src/3rdparty/protocol/
src/3rdparty/protocol/==>src/3rdparty/wayland/protocols/
src/extensions/qt-shell-unstable-v1.xml==>
src/extensions/
src/extensions/==>src/3rdparty/wayland/extensions/
src/client/
src/client/==>src/plugins/platforms/wayland/
src/global/
src/global/==>src/plugins/platforms/wayland/globalprivate/
src/shared/
src/shared/==>src/plugins/platforms/wayland/shared/
src/plugins/decorations/adwaita/==>
src/plugins/decorations/
src/plugins/decorations/==>src/plugins/platforms/wayland/plugins/decorations/
src/plugins/hardwareintegration/client/
src/plugins/hardwareintegration/client/==>src/plugins/platforms/wayland/plugins/hardwareintegration/
src/plugins/platform/
src/plugins/platform/==>src/plugins/platforms/wayland/plugins/platform/
src/plugins/shellintegration/qt-shell/==>
src/plugins/shellintegration/ivi-shell/==>
src/plugins/shellintegration/
src/plugins/shellintegration/==>src/plugins/platforms/wayland/plugins/shellintegration/
src/plugins/CMakeLists.txt
src/plugins/CMakeLists.txt==>src/plugins/platforms/wayland/plugins/CMakeLists.txt
src/qtwaylandscanner/
src/qtwaylandscanner/==>src/tools/qtwaylandscanner/
tests/auto/client/iviapplication/CMakeLists.txt==>
tests/auto/client/iviapplication/tst_iviapplication.cpp==>
tests/auto/client/shared/iviapplication.h==>
tests/auto/client/shared/iviapplication.cpp==>
tests/auto/client/
tests/auto/client/==>tests/auto/wayland/
tests/auto/cmake/test_waylandclient/
tests/auto/cmake/test_waylandclient/==>tests/auto/cmake/test_waylandclient/
Done-with: Alexandru Croitor <alexandru.croitor@qt.io>
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Task-number: QTBUG-133223
Change-Id: I46c325724141fdbfcc117d12fb5f92852613e72a
For Wayland protocols, "/usr/share/wayland-protocols/" is used on
Ubuntu/Debian derived, and same for arch. The share directory is
different with data and archdata directories.
Change-Id: I3bdd5bdc60bd4f66de66aecc943893978c86f19b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Don't write an absolute prefix into generated .pc files but one that's
relative to ${pcfiledir}. This makes the files relocatable, and we don't
have to patch them in the Qt online installer.
Pick-to: 6.8 6.9
Fixes: QTBUG-136210
Change-Id: I5c2f9398917be03f6c63286e553c87ff52971285
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
As qmltestrunner is not any longer qt tool.
Adjust the executable name and add the way to find
it outside the qtdeclarative.
Reflects the change in:
https://codereview.qt-project.org/c/qt/qtdeclarative/+/642618
Task-number: COIN-1211
Change-Id: I628de79f09cc27fb4d4fc43f297fcfb0c808ee19
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake MR #10626 doesn't consider the MSVC compiler as valid assembler
anymore, thus unconditionally requiring ASM breaks with CMake > 4.0.1 on
MSVC.
Enable ASM only on non-Android Unix.
Remove the ASM language where it's not needed.
Pick-to: 6.5 6.8 6.9
Change-Id: I5df71edfce0f4920e39262f722e4bf95a735f31b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently, configure fails late with
Qt requires at least version 15 of Xcode, you're building against
version . Please upgrade.
Pick-to: 6.9
Change-Id: Ic4f44d37429ac9def785a50909a25b0bcb4b72a5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If one of the interface link libraries of a target is
"$<LINK_ONLY:$<BUILD_LOCAL_INTERFACE:Foo>>"
this will be exported by cmake as
"$<LINK_ONLY:>"
in the exported INTERFACE_LINK_LIBRARIES property.
When walking the dependent libraries of a target using
__qt_internal_walk_libs(), this value will become empty after
unwrapping the LINK_ONLY genex.
In such a case, we should skip further processing of the library.
Otherwise in some weird unknown conditions, CMake might consider the
empty name to be a valid target, and cause errors when trying to read
properties from it.
Amends ad7b94e163ac5c3959a7e38d7f48536be288a187
Pick-to: 6.9
Fixes: QTBUG-136039
Change-Id: I143dec697e10530379486462697cd299940ee463
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This would allow us using Photos.framework/PHAssets on iOS (instead
of now-deprecated 'Assets' library).
Change-Id: I922e4765e8fdadf872f801b55a1e4ef4368e65b0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow generating files from template file. The signature first
expands the '@' wrapped variables in template file and then generates
the resulting file using file(GENERATE command.
Pick-to: 6.8 6.9
Change-Id: I0b4cf557da1d5161ffcde1c44aea98c440427980
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We should only pass PROJECT_COMMENT if it has a value.
We also need to escape semicolons, because the project comment might
contain the qt configure line, and that might have passed arguments
like -qpa offscreen\;xcb
Pick-to: 6.8 6.9
Change-Id: I934cf75c376b3466ba91a433d009e6eaa77a60fa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When processing multiple attribution files to collect all attribution
ids, the values of the previous iteration extracted keys were not
reset.
This caused the values to leak to the next processed attribution id
target if the specific id key was empty.
Make sure to clean up the values before parsing the next attribution
key.
Pick-to: 6.8 6.9
Change-Id: I386fc9c09276c49207382b06605efeb0d939b6da
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We should prevent using the invalid plugin class names at CMake
configure stage already, so users receive the early error.
Fixes: QTBUG-135860
Change-Id: I259539f6cce70a035ccf458a62d9e5a02f238ef8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Starting with CMake 4.0, CMake doesn't initialize the
CMAKE_OSX_SYSROOT variable with any value when running on a macOS
host and no explicit CMAKE_OSX_SYSROOT or CMAKE_SYSTEM_NAME is set.
CMake expects the platform compiler wrapper /usr/bin/c++ to pass an
appropriate -isysroot flag to the underlying compiler, without CMake
explicitly setting one.
This mostly works, but the configure output will not show anymore the
active sysroot path.
Query the active path from xcrun, and display it in the configure
output.
Pick-to: 6.8 6.9
Task-number: QTBUG-135621
Change-Id: Ic9b9a43e25bb88bb83165dce52356c77ea8fffe1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce two new functions _qt_internal_get_apple_xcrun_output
and _qt_internal_get_apple_sdk_name, to allow reusing them in the
future.
Make sure to set the output variables to empty even
outside Apple platforms.
Show an error when xcrun is called when targeting a non-Apple
platform.
Pick-to: 6.8 6.9
Change-Id: Ic3895f74cfcac337bff069f8e6ec1517aec6c8d0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
[ChangeLog][CMake] qt6_import_plugins doesn't have any effect anymore on
plugin deployment with the CMake deployment API on Linux.
[ChangeLog][CMake] qt6_deploy_runtime_dependencies now supports the
following plugin selection flags on Linux: INCLUDE_PLUGINS,
INCLUDE_PLUGIN_TYPES, EXCLUDE_PLUGINS, EXCLUDE_PLUGIN_TYPES.
Before this patch, we were deploying the plugins of every Qt module we
discovered when walking the dependencies of the target to be deployed.
That doesn't work if the target links against a shared library that
privately links against another Qt module, i.e. QtMultimedia like in the
bug report.
We need to take into account the Qt modules that are discovered when
retrieving the runtime dependencies at deployment time and deploy their
plugins.
Also, we now run file(GET_RUNTIME_DEPENDENCIES) and plugin discovery in
multiple passes. Every pass might discover new Qt plugins whose runtime
dependencies must be resolved. We stop if a pass did not discover new
plugins or after a certain number of passes.
Plugin discovery works like this:
- identify the Qt modules within resolved libraries,
- read the plugin types for the module from the corresponding,
module JSON file in Qt's installation,
- glob the files in Qt's plugins directory,
- select the files according to the plugin types from the Qt modules
and the INCLUDE.../EXCLUDE... arguments passed by the user.
We also read the default QPA platforms from modules/Gui.json and deploy
those.
Fixes: QTBUG-117731
Change-Id: I62ec96ab6de8327941c4c5a0ba83fd89f1733768
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Large graphical Qt applications heavily rely on heap allocations.
Jemalloc is a general-purpose malloc(3) implementation designed to
reduce heap fragmentation and improve scalability. It also provides
extensive tuning options.
Add a -jemalloc configure option, disabled by default. When enabled, Qt
and user code link to jemalloc, overriding the system's default
malloc().
Add cooperation with jemalloc for some Qt key classes: QArrayData (used
by QByteArray, QString and QList<T>), QBindingStoragePrivate,
QDataBuffer (used by the Qt Quick renderer), QDistanceFieldData,
QImageData, QObjectPrivate::TaggedSignalVector, QVarLengthArray.
This cooperation relies on two jemalloc-specific optimizations:
1. Efficient allocation via fittedMalloc():
Determine the actual allocation size using nallocx(), then adjust the
container’s capacity to match. This minimizes future reallocations.
Note: we round allocSize to a multiple of sizeof(T) to ensure that
we can later recompute the exact allocation size during deallocation.
2. Optimized deallocation via sizedFree():
Use sdallocx(), which is faster than free when the allocation size
is known, as it avoids internal size lookups.
Adapt the QVarLengthArray auto tests on capacity.
Non-standard functions docs are at https://jemalloc.net/jemalloc.3.html
[ChangeLog][QtCore] Added optional support for the jemalloc allocator,
and optimized memory allocations and deallocations in core Qt classes to
cooperate with it.
Change-Id: I6166e64e66876dee22662d3f3ea3e42a6647cfeb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
