summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: fix build with FreeBSD 13.1Thiago Macieira2022-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | I don't know if they've just added the libs and therefore the GSSAPI content wasn't enabled before, but libgssapi_krb5.so does not have the symbols we need. ld: error: undefined symbol: gss_acquire_cred >>> referenced by qauthenticator.cpp:1803 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1803) >>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView)) ld: error: undefined symbol: gss_release_name >>> referenced by qauthenticator.cpp:1808 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1808) >>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView)) [...] Change-Id: I6d3880c7d99d4fc494c8fffd16fabf70bbd272f5 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit c83a87eca7a435a6569e0185733982150093ee3a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Disable bitcode for iOSTor Arne Vestbø2022-08-181-1/+0
| | | | | | | | | | | It's deprecated as of Xcode 14, and generates a warning message if a project explicitly enables bitcode. The App Store no longer accepts bitcode submissions from Xcode 14. Change-Id: Ib1f9d5114ca4d8b1845ecc7a9de0473ee015db33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit e27a0d5a0f8818653ff125409db8187454409749) Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Override simulator architecture to x86_64 for Xcode generatorTor Arne Vestbø2022-08-151-2/+2
| | | | | | | | | | | | | | | The simulator build of Qt for iOS is currently x86_64 only, instead of universal builds with an arm64 slice as well, since we don't support xcframeworks. This means we can't rely on Xcode's default simulator arch settings, which on an Apple Silicon Mac will be arm64. Instead we override the simulator arch, like we do for qmake. Change-Id: I8b52389db1b83f4f9679c724bcde53b44dbc76f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 6ec21881dd68dfd88dee03b11036c3c862ccbbab) Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Fix detection of system double-conversionJoerg Bornemann2022-08-101-4/+9
| | | | | | | | | | | | | | | | | | | | | | | ...if the double-conversion CMake package cannot be loaded. The find_path call must specify the header exactly as it is included. The select_library_configurations call always failed, because the command expects the presence of DOUBLE_CONVERSIONS_LIBRARY_DEBUG, DOUBLE_CONVERSIONS_LIBRARY_RELEASE, or both. Upstream double-conversion's MSVC build system does not specify a naming scheme for the debug build, and there are no debug/release binaries to download that suggest a naming scheme. Therefore we assume the usual 'd' suffix for the debug library like we do everywhere else. Lastly, we need to set DOUBLE_CONVERSION_INCLUDE_DIRS. Fixes: QTBUG-105501 Change-Id: I71ff5238f353541b8bf5ac6792b86134deba20d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit a29af6656f1c33355c4cbfe8587b8f6eae691a21) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix examples to build as external projects when cross-compilingAlexandru Croitor2022-08-051-0/+35
| | | | | | | | | | | | | | We forwarded the compiler path to the EP but not the flags that might have been set via the CXX environment variable. Make sure to also forward the flags. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 7fb25609a41ab9cc20ddd62e90f30c0536502aef) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix Ninja Multi-Config dependency issues for top-level targetsAlexandru Croitor2022-08-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 0e2f218ee7b7ff96cc227f743aa6df11b86a74fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Relax constraint on not having feature values changeAlexandru Croitor2022-08-031-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if qtbase was built with feature A set to ON, then building qtsvg, then rebuilding qtbase with feature A set to OFF, trying to build qtsvg would fail with an error message at configure time saying that the feature value has changed. This check was added quite early in the Qt CMake port, presumably to catch accidental reconfigures that might cause long rebuilds. This has dubious benefit though. We constantly had people telling us they get the error without knowing what to do. The usual advice was to remove CMakeCache.txt and reconfigure. Instead of forcing people to suffer this dance, relax the constraint by issuing a warning instead of an error, and make it more clear why a rebuild might happen (a changed feature value might change the generated module C++ header file which in turn might be included by various project sources). Amends 20633d97abed0f6025572f87c9359272b4713384 Fixes: QTBUG-95834 Change-Id: I992bd61024958869f3b995471b4c7ff75e3a33a0 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 15117f84bb9a5fd191105b2a4d8ebafc6c819fb9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix single standalone tests to use same Qt C++ language stdAlexandru Croitor2022-08-032-1/+5
| | | | | | | | | | | | | | | | | | When using qt-cmake-standalone-test, we didn't tell CMake to use the same C++ language standard that Qt used when it was configured. We did tell CMake to do that when configuring tests with qt-internal-configure-tests via the qt_build_tests macro. To ensure the proper standard is set, we also need to find_package(Qt6Core), because the std flag is derived from the QT_FEATURE_cxxyz flag which is set by Core. Change-Id: Ia41f2a24983ddab0107a6446743f7b054df8c033 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit effd6f63f1a4b7dc7b5e6bca41594f1d1562a713) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix install destination of in-tree examplesAlexandru Croitor2022-07-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we called _qt_internal_override_example_install_dir_to_dot in Qt6CoreConfigExtras.cmake as part of a find_package(Qt6 COMPONENTS Core) call, and we assumed that the Extras file would always be included in each example project. But our package dependencies handling code skips calling find_package(Qt6Core) if Qt6Core_FOUND is already set to TRUE, which will definitely happen due to root-scope find_package calls when configuring other repos. That means we wouldn't override INSTALL_EXAMPLEDIR to "." and the install destination would end up being something like ${CMAKE_INSTALL_PREFIX}/example_relative_path/example_relative_path aka a double nested path. Make sure we call the _qt_internal_override_example_install_dir_to_dot function in Qt6ConfigConfig.cmake in addition to Qt6CoreConfig.cmake. That way, even if Qt6Core is skipped during dependency resolution, it's still handled by the Qt6 package itself. Because the function is defined in the Core package, guard the call with an if(COMMAND) and only call the function if it wasn't previously called within the current or ancestor scopes. Amends ac4a913f333561803003650817de453f43be924d Fixes: QTBUG-102879 Change-Id: Id47e3ce06faec6d156ae1473942dae0f9b90cb46 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit 0e0352ab4d38ca31bb8e488783e35c2f8955e540) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: prepend build dir for examples buildSamuli Piippo2022-07-261-6/+6
| | | | | | | | | | | | | In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the host Qt and examples build will pick up wrong Qt6Config.cmake unless the build dir path is prepended. Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 18ed6a8979a1f1910f1285b5b2e5a28c397b37aa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: include the libexecdir in generated pkg-config filesEli Schwartz2022-07-261-0/+1
| | | | | | | | | | | | | | | | In Qt6, the installed tools can be in one of two different locations, depending on whether it is considered a helper or not. This means that when migrating from Qt5 to Qt6, the pkg-config files no longer reliably described where to find tools such as moc, uic, and rcc, which third-party projects need to know about in their build systems. Add this information in, to match qmake -query and Qt6CoreConfigExtras.cmake Task-number: QTBUG-105051 Change-Id: I6692a76e0491a1c5e28982aa5fbe8b8aec8dec56 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit d8f9ac784e919064ab2620a3bd77794d6e730c9a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Ensure build instructions are always shown the first timeAlexandru Croitor2022-07-261-1/+8
| | | | | | | | | | | | | Regardless of the current log level. Somewhat similar to dd5c860a7b5f5bf347b698b9145c45d369325e42 Amends e2a0ddbb69640c94b4ee107260a088d5c1c7e273 Change-Id: Ib7bc87f07e195125c858dcece2df6e82303dd01c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit 12629c6b808e476b474e6db98ae5ded64f5fc44f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Propagate qtbase's original staging prefix to other Qt reposJoerg Bornemann2022-07-151-14/+27
| | | | | | | | | | | | | | | | | | | | | | | If qtbase was configured with CMAKE_STAGING_PREFIX set to a path without drive letter on Windows, we must ensure that this exact staging prefix is propagated to non-qtbase repos. We already had code that does this for CMAKE_INSTALL_PREFIX. But since 9a74d94ff5fa63bfb23dcad1209e2844ef39908b we build our cross-built packages with CMAKE_STAGING_PREFIX instead of CMAKE_INSTALL_PREFIX. Move said code into a function and use it for CMAKE_STAGING_PREFIX too. This fixes Android non-qtbase release libraries not being stripped in our Windows Android packages. This amends commit 037fd545c485e73ac68377a264c84208592dc74f. Fixes: QTBUG-104827 Change-Id: I909f7f39bd0ef7b559619b69f756c042d6c528b0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 8cc58fbbc70d45ce29dab3c50638d33765bebcf9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* cmake: Don't reference global data in qt_internal_get_title_caseTor Arne Vestbø2022-07-141-1/+1
| | | | | | | | | | The only place the function was used was to generate the title case of a target, so the issue wasn't spotted until now. Change-Id: Iee66ecea569e7411c6b5a5e5312cde910a48fa01 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 3ad0f755f56eae4e8d94459f7cc17671e51e95da) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix qml plugin prl files not to have hardcoded pathsAlexandru Croitor2022-07-052-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous fix 754512a64dffa20165e5b08b77e34b82c072f7f8 did not handle qml plugins, which meant that they would still have hardcoded paths and see warnings like the one below when generating the prl files CMake Warning (dev) at cmake/QtFinishPrlFile.cmake:103 (message): Could not determine relative path for library qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a when generating prl file contents. An absolute path will be embedded, which will cause issues if the Qt installation is relocated. Handle qml plugins as well. Amends 754512a64dffa20165e5b08b77e34b82c072f7f8 Amends f4e998125981038e5e50dab8cc56039faaa0b750 Fixes: QTBUG-104708 Task-number: QTBUG-104396 Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit 9ea2f7f4b1192f3429aa2d3e278097008bc773bb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Don't force CONFIG mode when looking for system PCRE2Alexandru Croitor2022-07-051-1/+5
| | | | | | | | | | | | | | | | This allows picking up 3rd party Find modules. One use case is Conan-generated Find modules. Also add TODO in case we ever need to handle finding the upstream target name rather than the Hunter chosen one. Fixes: QTBUG-104542 Change-Id: I243987c657f74e8127076666d9734b2b657bc0ee Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit af56a6f0cb61b45b13fe9efde12bc39b01030fc7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix confusing FPHSA zstd version warning messageAlexandru Croitor2022-07-051-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously if zstd was not found, one would see such a warning message Could NOT find WrapZSTD: Found unsuitable version "", but required is at least "1.3" (found ZSTD_LIBRARY-NOTFOUND) This is because PC_ZSTD_VERSION was a defined variable with an empty value, which makes FPHSA believe that a version was extracted from somewhere. Avoid passing that value directly. Now the warning message is Could NOT find WrapZSTD (missing: ZSTD_LIBRARIES ZSTD_INCLUDE_DIRS) (Required is at least version "1.3") Change-Id: I88760d94db0d869d328085996298f4aaa88bc6c2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit d59628881e0b35d10fa4cf7ba7b892b07cc18106) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Rewrite double-conversion find moduleAlexandru Croitor2022-07-053-54/+77
| | | | | | | | | | | | | | | | | | | | Rename FindWrapDoubleConversion.cmake into FindWrapSystemDoubleConversion.cmake. Merge contents of Finddouble-conversion.cmake into the one above. This allows users to provide their own Finddouble-conversion.cmake file (Conan can do it). Don't mark the system package as required, because we have a bundled one too. Add link to upstream. Make sure to show either Config file or library path when one is found. Fixes: QTBUG-104541 Change-Id: I9ea2330697c6fc280328849ca11522291c4073d8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit a310319a0409c1faa1d2fc83c740e009f46dba84) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix lookup of system PCRE2 versionAlexandru Croitor2022-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | The version option needs to be specified before the COMPONENTS option, otherwise it is treated as another component. This causes failures when a Conan provided FindPCRE2.cmake script is picked up, which actually does validation of component names based on the component information stored in the conanfile.py recipe. Move the version value to be before COMPONENTS. Amends 1007aac63a378c1b09f221f9b58b65bb56f9e9e8 Task-number: QTBUG-104542 Change-Id: I92c70f266a07c4aabdadcecda1ba7e107a033604 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit bfd9e195a3b5312c3814a933bbc1bc5d9c76973e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Improve 'Generating Plugins' messageAlexandru Croitor2022-07-051-1/+6
| | | | | | | | | | | | | | | Use message(STATUS) for the 'Generating Plugins' message. This way it will go to stdout instead of stderr, which follows the convention we have for most of our other messages. Also list only the modules that actually have plugins, rather than all known modules. Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit eb8da02d055f8f761880da33b02342ca2d69b1a5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Don't show the incompatible version warning when not neededAlexandru Croitor2022-07-011-1/+9
| | | | | | | | | | | | | | | | | If a find_package(Qt6Foo) call has the QUIET option passed, don't display the incompatible version warning. Also if the find_package call has the EXACT option passed, and the searched for version does not match the package version exactly, there's no point in showing the warning because find_package will reject the package anyway, even if we set PACKAGE_VERSION_COMPATIBLE to TRUE Change-Id: I78ef95cf4a045034fc50853465f3ba1db84bba63 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 74d832177169dd24ff06c9a584d0dc0f4f35d31b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* headerclean: remove dead codeMarc Mutz2022-06-301-4/+0
| | | | | | | | | | | | | The variable was misspelt, so we obviously don't need these exceptions. Manual conflict resolutions: - cmake/QtHeadersClean.cmake Change-Id: I691c9315bcde3aad72410ce01ae6dc6a013ee6fd Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit 06f21a387069fe02d6e97600fc445a3c71b0fb82) Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix prl files not to contain hard-coded library pathsAlexandru Croitor2022-06-232-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | Make sure to convert absolute paths generated using the $<TARGET_LINKER_FILE> generator expressions into relative paths. Because prl files are generated for both modules and plugins, we need to pass both a list of qt module locations and qt plugin locations to QtFinishPrl.cmake, and then try to make the absolute path relative to each passed directory. A warning assertion is shown if we no relative path could be made, which will cause an absolute path to be embedded. This should not happen though. Amends f4e998125981038e5e50dab8cc56039faaa0b750 Fixes: QTBUG-104396 Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 754512a64dffa20165e5b08b77e34b82c072f7f8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Warn when using CMake 3.21.1Alexandru Croitor2022-06-171-0/+6
| | | | | | | | | | | | | | | | | | Changing a C++ source file can trigger rebuilds of a lot of other source files that might include AUTOGEN'ed headers or sources. See https://gitlab.kitware.com/cmake/cmake/-/issues/22531 for some details. Fixed in CMake 3.21.2. There are still files that are rebuilt even in 3.21.2, but it's less, and it returns to the status quo of how it was in 3.21.0 or earlier versions. Task-number: QTBUG-104352 Change-Id: Ie1c991d52df48442d4134e4ed22a8137a3c993c8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit b3e3b124892d01adeba378aac45224b2dea04fde) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Find system harfbuzz even if pkg-config is disabledJoerg Bornemann2022-06-161-9/+26
| | | | | | | | | | | | FindWrapSystemHarfbuzz.cmake relied on pkg-config to find system harfbuzz. This patch makes it find system harfbuzz even if pkg-config is not available or disabled. Task-number: QTBUG-103894 Change-Id: I2a8fc64c738c7604f47de89f387002e40a9fa5e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit f318c0e2d68ec0a3a98de43fcbaf51f84d5eb8a6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Make configure -no-pkg-config actually workJoerg Bornemann2022-06-151-3/+8
| | | | | | | | | | | | | | Turning off pkg-config with the configure flag -no-pkg-config did not work. There are different defaults for FEATURE_pkg_config on different platforms (e.g. Linux: ON, Windows: OFF). The existing code that calculated the initial FEATURE_pkg_config value assumed that the default is OFF and never turned the feature off. Fixes: QTBUG-104123 Change-Id: I33b9687c55c60d4ec9224324951a8838741ee976 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 4cef4f1c1be713e932052968ac853ec37750ae61) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix check for system harfbuzz if pkg-config is unavailableJoerg Bornemann2022-06-141-12/+13
| | | | | | | | | | | We need to check whether pkg_check_modules returns success before setting up target name etc. Fixes: QTBUG-103894 Change-Id: I12702639683723d976e93be95443099b88885869 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 71a0b893fb4beb15df4a6bfe540518e5267fdb40) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Disable CMAKE_INSTALL_RPATH_USE_LINK_PATHAlexandru Croitor2022-06-131-11/+9
| | | | | | | | | | | | There should be no need for CMake to add rpaths pointing to directories outside of the build tree to the installed libraries. All relevant install rpaths are handled by qt_apply_rpaths(). Fixes: QTBUG-103777 Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit a1d8b9023f499560b967965ef52af2a7de981727)
* CMake: Fix implementation of qt_apply_rpathsAlexandru Croitor2022-06-131-14/+44
| | | | | | | | | | | | | | | | | | | | | | | | There were a few things that were not ported correctly. Make sure to disable rpath manipulation if the rpath feature is disabled. Fix if(IS_ABSOLUTE) conditions to actually take values. Don't embed bogus relative rpaths if the platform does not support it. QNX is such a platform, it does not support $ORIGIN (at least from my scouring of QNX documentation and manual testing via QEMU). Handle the extra rpath case where they are relative, but the platform does not support relative rpaths, by transforming them into absolute ones. Amends 67ee92f4d898ee76c40b7efd8e69782a6a4a3754 Task-number: QTBUG-103777 Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 8254ee6a3bc6310cd7701450cc000fb04bf85671)
* CMake: Ensure top-level builds are affected by our chosen log levelAlexandru Croitor2022-06-132-11/+33
| | | | | | | | | | | | This will hide the configuration summary and cmake feature summary and found packages output upon reconfiguration. Task-number: QTBUG-104128 Change-Id: I42270b99e45076052ec176df4652661cae10ac0c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit b3d0325a8dca56d3163451a417edfe6015a4ffe0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Show configuration summary on first configurationAlexandru Croitor2022-06-131-5/+38
| | | | | | | | | | | | | | | | | | | | | | or when feature changes are detected, even when the log-level is set to NOTICE (which is the default for non-developer-builds). We want to show the summary during the first configuration so we don't force users to look into the config.summary file. We want not to show the summary upon reconfigurations, to keep regular reconfigurations as quiet as possibe, so it's easy to notice any new warnings. Amends e2a0ddbb69640c94b4ee107260a088d5c1c7e273 Amends 384dfceb532cada5f4be96430c8c7c866f40c933 Fixes: QTBUG-104127 Change-Id: I506f33b4bae9da8957e04bb69c206bf00e3f7b0e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit dd5c860a7b5f5bf347b698b9145c45d369325e42) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Use the PRODUCT_NAME for the iOS display name like qmakeAlexandru Croitor2022-06-091-0/+7
| | | | | | | | | | | | | | | | | | | This ensures that the Xcode 'Display name' input under ${target} -> General -> Identity -> Display name is not empty. Because adding ${PRODUCT_NAME} directly in the Info.plist.in template will cause CMake to evaluate it as variable expansion, work around the issue by putting the dollar sign into a separate cache variable that after evaluation will result in ${PRODUCT_NAME} being in the file verbatim, so that Xcode evaluate it at build time. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Task-number: QTBUG-95838 Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit 55eb94cdbdf1b1fbd6424aa06921bc79123f88cd)
* CMake: Automatically use Xcode generator in qt-cmake + iOSAlexandru Croitor2022-06-091-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling qt-cmake on the command line, we don't usually force usage of a particular CMake generator and defer to the user's choice or CMake's default for the host OS. In the case of iOS, the generator that makes the most sense to use is Xcode. One could also use Ninja / Unix Makefiles if the project is only building static libraries, but for shared libraries and executables the project likely needs the code signing provided by xcodebuild. When targeting iOS, use a different qt-cmake file template. The iOS-specific shell script will set the CMAKE_GENERATOR environment variable to 'Xcode'. If no -G or -D CMAKE_GENERATOR is provided on the command line then the project will use the Xcode generator. Otherwise the generator given on the command line takes precedence. The CMAKE_GENERATOR environment variable from the parent process is completely ignored. The logic is only done for iOS, to reduce the likeliness of breaking the qt-cmake script for other platforms. Note that Qt Creator does not use qt-cmake, but rather calls cmake directly with additional options like the toolchain file, architecture, sysroot, etc. [ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode generator when targeting iOS projects. Fixes: QTBUG-100834 Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit a3917126e821ca8f5f5d423a65344a2f9663250c) Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix typo in error messageJoerg Bornemann2022-06-031-1/+1
| | | | | | | Change-Id: Iace4fe19c0bdbcb61f667363d86b22abf6ec7d24 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 687f22671f97b315d4cb8d7f1c9e511fc765f480) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix line endings of wrapper scriptsJoerg Bornemann2022-06-032-11/+23
| | | | | | | | | | | | | | | | | If QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS is ON then we generate Windows scripts on Unix and vice versa. We always used the host platforms line endings for generating the scripts. This leads to Windows line endings in Unix scripts and vice versa. Explicitly specify the line endings style when generating wrapper scripts. Fixes: QTBUG-102747 Change-Id: I1603add46f276a5d91bbf0f103a261cdd84c343b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit 6dffc1c438062e69609e281e56633f4a7821402e) Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix issue with linking against static library on iOSAlexandru Croitor2022-06-031-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently our iOS CMake toolchain file sets the global XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work around a CMake issue regarding usage of object libraries in conjunction with Xcode. The error was The OBJECT library type may not be used for IMPORTED libraries under Xcode with multiple architectures $(CURRENT_ARCH) While this got rid of the error, it introduced a regression where linking an executable against a static library in the same project failed due to the library not being placed in a directory where Xcode expects it to be. clang: error: no such file or directory: '~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a' The actual library is created in Debug-iphoneos/libuntitled4.a Note the -iphoneos suffix, which is related to the EFFECTIVE_PLATFORM_NAME. This could be further worked around by either explicitly setting the library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the end of the project. Both workarounds are not project-friendly. In the mean time CMake got a fix for the original error at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771 which got released with CMake 3.20.0. That was unfortunately not sufficient to remove our initial workaround, because removing it would trigger a different error at generation time CMake Error: Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Quick_resources_1> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake (limited under Xcode with multiple architectures). It is not suitable for writing out elsewhere. Fortunately, another fix landed in CMake 3.21.0 to address that https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161 Because static builds (iOS) require CMake 3.21, with both of these fixes we can now remove our workaround. Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work fine. This also fixes installation of libraries, which also took into account the effective platform name and thus caused a mismatch between the expected output dir and the real one. This reverts 1e1805ed36a932dcb085a1ad3308782a136d477c Fixes: QTBUG-93268 Fixes: QTBUG-95381 Task-number: QTBUG-87198 Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit c0188b2dbd7e34b359b091865f19b87bc12d7bd5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix interleaved configure outputAlexandru Croitor2022-05-231-0/+5
| | | | | | | | | | | | | | | | | | | | message(STATUS) prints output to a buffered stdout, whereas message(NOTICE) or just message() print to unbuffered stderr. We use a mix of message() calls when printing the configuration summary, which caused interleaved output. Because CMake offers no message(FLUSH), we work around the issue by calling execute_process(COMMAND -E echo " ") which does call std::cout << s << std::flush; We seem to have to do it twice, before and after the detailed configuration summary is printed. Change-Id: Ibc075551fc0547073f0696477e54d9b9c1edca97 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit dc4bc1e575a6e085f76200f9e4b96c6fb84cf313) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Sync rpath documentation with the current implementationAlexandru Croitor2022-05-231-9/+25
| | | | | | Change-Id: Id3af1cdfd66cd9527ab76137d72e354edfc3de75 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit e28a32ea450d1e1fa3a813a41cb439126dd93dbc)
* CMake: Print prefix info when building qtbaseAlexandru Croitor2022-05-231-0/+9
| | | | | | Change-Id: Ib76d94b1c51f99d5ce007d463d97b5d2b256d2bf Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit e327ed191c69898cd82e4b7b2ee73b790b7c81b7)
* CMake: An -extprefix -developer-build should install by defaultAlexandru Croitor2022-05-231-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if -extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX) -developer-build (FEATURE_developer_build) were specified, but -prefix (CMAKE_INSTALL_PREFIX) was not, the build system would set the CMAKE_INSTALL_PREFIX to the qtbase build dir. Then, if targeting desktop, this would be considered a non-prefix build (ninja install would refuse to work), whereas in a cross-build it would be considered an installable build. In both cases though, the rpath of installed binaries would point to the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the qtbase build dir). This is quite confusing behavior, in more than one way. Change the build system to consider that an explicit -extprefix should cause Qt to always be installed, even if -developer-build is specified. This means the installed rpaths and on-device install prefix (CMAKE_INSTALL_PREFIX) will now use the default computed install prefix, e.g. /usr/local/Qt It also means that to get a non-installable developer + custom staging and install (on-device) prefix build, users will have to be explicit and set all the options -extprefix ~/qt/qtbase_build_dir -prefix /usr -developer-build Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 5059f7adc2abbfe6085a7b9dd04cd8463e1a412a)
* CMake: Allow no install + custom on-device prefix for desktop buildsAlexandru Croitor2022-05-233-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit f3483e6b962efd03ccf7633cb68f0c3b91b5c07c)
* CMake: Fix static library link order when using qmakeAlexandru Croitor2022-05-232-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qmake adds QMAKE_PRL_LIBS values on the link line after the currently processed library. Because CMake adds resource object files into QMAKE_PRL_LIBS, they end up on the link line after the library. This causes issues on Linux with GNU ld and ld.gold, because the linker discards symbols from the library which are then later referenced by the object files. Work around that by placing the path to the library directly into QMAKE_PRL_LIBS after the resource object files. This ensures the linker doesn't discard the symbols required by the resource object files. This means that each library encountered in qmake's LIBS variable will be temporarily referenced twice in qmake's project state: once from LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are added. On the link line it will appear only once though, because qmake does library deduplication during prl file processing, which only keeps the last occurrence. Amends 4ab54320817ebbb465af343514d21139a654aed3 Fixes: QTBUG-103002 Change-Id: I97647b64de22b158424850915fee62b5fea5f995 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit f4e998125981038e5e50dab8cc56039faaa0b750) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Handle strip wrapper creation more robustlyAlexandru Croitor2022-05-231-11/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unsetting CMAKE_STRIP and including CMakeFindBinUtils to find it again is not safe, because CMakeFindBinUtils has logic to search for additional tool names depending on the currently processed language. The currently processed language is set in _CMAKE_PROCESSING_LANGUAGE only when CMake is doing it's language introspection via CMakeCXXCompiler.cmake. This resulted in the build system finding a regular host-OS strip, rather than an android specific llvm-strip when doing an Android build, which then silently failed to strip the Android libraries and caused us to ship big binaries. Improve the strip wrapper creation in a few ways: - Save the original strip value on first configuration - Restore it if needed, without using CMakeFindBinUtils - Don't apply the strip wrapper creation logic to Android, we currently don't need it there - Add some informational messages about which CMAKE_STRIP ends up being used even if log-level is not DEBUG - Fix a typo Amends 39f657032b5e65bfcb93472201f6607c0388ba37 Fixes: QTBUG-103356 Task-number: QTBUG-101653 Change-Id: I23d98180446d5bb7628e783668f46e4e546ed700 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> (cherry picked from commit ff0ee3d98551c128f33a289c61ff86ae3baab1da) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Cherry-pick qt-testrunner.py from dev branchDimitrios Apostolou2022-05-192-0/+3
| | | | | | Task-number: QTBUG-96353 Change-Id: I5be469a44a306ebe2eada4983dc971e576ad0637 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Explicitly check for atomic addition and relaxed load operation supportMoody Liu2022-04-181-15/+19
| | | | | | | | | | | | | ...and properly find and link against `libatomic` using find_library. This fixes the qtdeclarative build on the RISC-V platform. Initial-patch-by: Sprite <SpriteOvO@gmail.com> Task-number: QTBUG-99234 Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 4088b27b9397fa9877bf60b8e707bba5dc51e9cb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Suppress cmake warning about empty string argumentAlexey Edelev2022-04-121-1/+7
| | | | | | | | | | | | | | | | When generating .pc files there is a warning when executing QtFinishPkgConfigFile.cmake: Ignoring empty string ("") provided on the command line. This happens because the 'postfix' argument is a part of the script command line even if it's empty. It also makes no sense to check if 'postfix' is empty using genex, use configuring-time check instead. Change-Id: If52d9634f4885caefb828976b3c99592a6db3d3c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 8eef32d460d06f823fa20b364e3ffe6ca5cd6977) Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Remove the LINK_LANGUAGE genex condition when generating .pc fileAlexey Edelev2022-04-121-0/+1
| | | | | | | | | | | | | Conditions with the LINK_LANGUAGE genex are not parsed correctly when generating .pc file. So link options will be added unconditionally. Amends d1e02c385539ce971fbad207ba9aaa32be9c7bac Fixes: QTBUG-101723 Change-Id: Ib837b3f3429d195a469450ef25af9630ad7d15e2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 97ef7752a2db871d45c8e434d15e0ccec015cd65) Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake build: generate pkgconfig for public modulesMartin Reboredo2022-04-128-18/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 5b07f14a4ff6b08887473b1b583ee2f71dec6f76) Reviewed-by: Martin Reboredo <yakoyoku@gmail.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix check for pcre2 using cmakeJonas Kvinge2022-04-091-1/+1
| | | | | | | | | | | | | | | When PCRE2 is compiled using cmake, a pcre2 cmake file is installed and Qt fails to configure because components isn't specified for find_package. In recent PCRE2 releases components needs to be specified for find_package. Fixes: QTBUG-102358 Change-Id: Ib842b2c4b1c0bf38aa5da5475eaa2b3c56c6b822 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 1007aac63a378c1b09f221f9b58b65bb56f9e9e8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Reorganize work with graphical libraries on INTEGRITYTatiana Borisova2022-04-053-0/+33
| | | | | | | | | | | | | - Currently we manually unpack all platform libraries, that are required for GUI apps, and pack it into single eglmegapack.a library. It could be better do not execute such additional step, but have possibility to add required graphical libs to cmake interface lib via toolchain file list variable. Change-Id: Ic4122600f02e6828d528ee4f00075f8c27f42e38 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 8116fdde1c13fe00fb03414b56da2d66e215f279) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 06:23:47 +0000