summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix qml plugin prl files not to have hardcoded pathsAlexandru Croitor2022-07-022-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 Pick-to: 6.2 6.3 6.4 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>
* CMake: Fix confusing FPHSA zstd version warning messageAlexandru Croitor2022-07-021-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") Pick-to: 6.2 6.3 6.4 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>
* CMake: Rewrite double-conversion find moduleAlexandru Croitor2022-07-023-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. Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104541 Change-Id: I9ea2330697c6fc280328849ca11522291c4073d8 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't force CONFIG mode when looking for system PCRE2Alexandru Croitor2022-07-021-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. Pick-to: 6.2 6.3 6.4 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>
* CMake: Fix lookup of system PCRE2 versionAlexandru Croitor2022-07-021-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 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-104542 Change-Id: I92c70f266a07c4aabdadcecda1ba7e107a033604 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Record used package version for each target dependencyAlexandru Croitor2022-07-0110-13/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.2 6.3 6.4 Change-Id: I78ef95cf4a045034fc50853465f3ba1db84bba63 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: update the x86 intrinsic checksThiago Macieira2022-06-282-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | Merge all the existing checks into a single one, which is a simple pass or fail, since all our supported compilers support all the intrinsics up to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES) aren't yet supported everywhere, so they stay. For some reason, all intrinsics seem to be disabled on Android. It looks like some support was missing during the CMake port and this was never again looked at. I'm leaving it be. As for WASM, discussion with maintainers is that the WASM emulation of x86 intrinsics is too hit-and-miss. No one is testing the performance, particularly the person writing such code (me). They also have some non-obvious selection of what is supported natively and what is merely emulated. Using the actual WASM intrinsics is preferred, but someone else's job. Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: disable the attempt to force SIMD on iOS simulator buildsThiago Macieira2022-06-272-12/+4
| | | | | | | | | | | This will stop working with the next commit, which merges all basic x86 SIMD intrinsics into one configure test. As a result, linking almost anything graphical on iOS (which is almost everything) causes the linker to fail with undefined references to SIMD-optimized versions that didn't get compiled. Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Doc: Skip 'qt5/' part in 3rd party documentationKai Köhne2022-06-231-0/+1
| | | | | | | | Pick-to: 6.4 Fixes: QTBUG-104463 Change-Id: I7596118e147c9b5b12b49c4cf2692626697f309e Reviewed-by: Andy Shaw <andy.shaw@qt.io> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* CMake: fix build with FreeBSD 13.1Thiago Macieira2022-06-221-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)) [...] Pick-to: 6.2 6.3 6.4 Change-Id: I6d3880c7d99d4fc494c8fffd16fabf70bbd272f5 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix prl files not to contain hard-coded library pathsAlexandru Croitor2022-06-222-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 Pick-to: 6.2 6.3 6.4 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>
* wasm: Optimize use of openglesLorn Potter2022-06-221-11/+1
| | | | | | | | | | | | | | - USE_WEBGL2 is depreciated, Emscripten now uses MAX_WEBGL_VERSION - Optimize and remove use of emulated ES2 and ES3, which means only use WebGL friendly subset. Users can add USE_ES3=1 and USE_ES2=1 to the final linker arguments for those respective versions in order to enable using glDrawArrays and glDrawElements with unbound buffers. See https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html Pick-to: 6.4 Change-Id: I11ae359966964b3e7aa6e61ccc714c2bfbf61f96 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* headerclean: remove dead codeMarc Mutz2022-06-221-4/+0
| | | | | | | | | The variable was misspelt, so we obviously don't need these exceptions. Pick-to: 6.4 6.3 6.2 Change-Id: I691c9315bcde3aad72410ce01ae6dc6a013ee6fd Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Long live QT_INLINE_SINCE!Marc Mutz2022-06-221-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have now had several requests for inlining previously-exported member functions, but no standard mechanism to effect it. As QT_REMOVED_SINCE has shown, there is great value in having such a standard mechanism, so here is one. With this change, to inline a previously exported (member) function, simply - mark the declaration with QT_<MODULE>_INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE - #include the header into the module's removed_api.cpp Just including the header into removed_api.cpp is enough, so you may want to add a comment: #include "header.h" // uses QT_<MODULE>_INLINE_SINCE The effect is as follows: - A TU in a _different_ library will see an inline declaration, followed by the definition, and so it will see a normal inline function. - A TU in the same library will, however, see a non-inline declaration, to avoid the ODR violation that at least GCC/ld are able to detect. - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also see the definition, which is the same setup as before the change, except in a different TU, and therefore export the member. - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the TU will see no declaration, assuming (correctly), that the definition will be supplied by a different TU. This is, of course, an ODR violation, but not worse than what we do elsewhere, as the definitions differ only between library and user. The function is inline only for the users of the library, not the library itself, which will still see the function as non-inline. If inlining is critical within the library, too, the existing function should call a new inline function, and calls in the same library should be changed to call the new inline function instead. Use the new mechanism to inline the QLocale ctor we intended to inline for 6.3, but couldn't, because we hadn't found the magic incantation, yet. Thiago found it a few weeks later, and this is what this patch is based on. Fixes: QTBUG-100452 Pick-to: 6.4 Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Mark chosen C++ standard as required for building QtYuhang Zhao2022-06-192-0/+9
| | | | | | Change-Id: I7d3187e74251059c7536f3e34d8c87f54c673146 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing argument to list(APPEND in __qt_internal_get_tool_imported_locationAlexey Edelev2022-06-171-1/+1
| | | | | | | | Amends f9e48854af4a25f13f593dd151071c8eda53b65f Pick-to: 6.4 Change-Id: Iea525c70cca9873c0f3d96967af6cd95d57cac9b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Warn when using CMake 3.21.1Alexandru Croitor2022-06-161-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. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-104352 Change-Id: Ie1c991d52df48442d4134e4ed22a8137a3c993c8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add ASAN build for qtbaseDimitrios Apostolou2022-06-151-1/+3
| | | | | | | | | | | | | | | The test run is wrapped with a special TESTRUNNER script that ignores failing tests (there are several tests failing when built with ASAN) and also ignores LSAN errors (memory leaks - but still visible in the output). The test run only fails if a test reports ASAN errors or if it crashes (or times out, which is like a crash caused by qtestlib's watchdog timer). Fixes: QTQAINFRA-5025 Change-Id: I861756ab49388ac4a52409d3a780684244e469b1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* modulecppexports.h.in: re-indent nested preprocessor directivesMarc Mutz2022-06-141-3/+3
| | | | | | | | | Amends 0d9f4e7526fbf1e072aa3518e4e5313332ee4f18. Task-number: QTBUG-100452 Pick-to: 6.4 6.3 6.2 Change-Id: Iaa6626853a4241f750a6929fc9f604a149c874eb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Fix typosKai Köhne2022-06-1316-21/+22
| | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: up the minimum C version to C11Thiago Macieira2022-06-111-5/+2
| | | | | | | | | We're in 2022. A 11-year-old C standard probably suffices, especially since we require C++17 anyway. Pick-to: 6.4 Change-Id: Ibcde9b9795ad42ac9978fffd16f3555327097ded Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Ensure top-level builds are affected by our chosen log levelAlexandru Croitor2022-06-102-11/+33
| | | | | | | | | | | This will hide the configuration summary and cmake feature summary and found packages output upon reconfiguration. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-104128 Change-Id: I42270b99e45076052ec176df4652661cae10ac0c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Show configuration summary on first configurationAlexandru Croitor2022-06-101-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 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104127 Change-Id: I506f33b4bae9da8957e04bb69c206bf00e3f7b0e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Find system harfbuzz even if pkg-config is disabledJoerg Bornemann2022-06-101-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. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-103894 Change-Id: I2a8fc64c738c7604f47de89f387002e40a9fa5e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix check for system harfbuzz if pkg-config is unavailableJoerg Bornemann2022-06-101-12/+13
| | | | | | | | | | We need to check whether pkg_check_modules returns success before setting up target name etc. Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-103894 Change-Id: I12702639683723d976e93be95443099b88885869 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make configure -no-pkg-config actually workJoerg Bornemann2022-06-101-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. Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-104123 Change-Id: I33b9687c55c60d4ec9224324951a8838741ee976 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* C++23/c++2b supportAllan Sandfeld Jensen2022-06-082-2/+6
| | | | | Change-Id: I33b2a48312ae94e3d5ebb4097e50c4953e14d533 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* wasm: Replace depreciated --embind compiler argumentLorn Potter2022-06-021-1/+2
| | | | | | | | As of Emscripten 3.1.3, the --embind compiler argment has been depreciated for -lembind Change-Id: Iac5bc21602f27fda7c1ea6814a1c9525b9a5afab Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* wasm: don't enable specialHTMLTargets by defaultMorten Sørvig2022-06-011-1/+1
| | | | | | | | | | | | | | | | | | Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the obligation to actually use it as well; failing to do so makes Emscripten stop with a reference error on startup. However, we can't guarantee that Qt will use it in all cases. The current usage depends on QGuiApplication being used. Application code could be using QCoreApplication, or no application object at all. Detect if specialHTMLTargets is present instead, and then enable the code paths which uses it if that's the case. This means that apps which want to use e.g. multiple browser windows can opt into support by making sure EXPORTED_RUNTIME_METHODS contains specialHTMLTargets. Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Avoid some new clang 14 warnings on Android NDK 24 buildVille Voutilainen2022-05-271-0/+5
| | | | | | | Task-number: QTBUG-99663 Change-Id: I1aa408ba468342e2fac2323ae91ff650b871c563 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Adjust installing and running wasm-testrunnerDavid Skoland2022-05-272-4/+17
| | | | | | | | | | Added a small helper function that also installs the script to prefix builds. Additionally, leveraging the cmake option CROSSCOMPILING_EMULATOR for the testrunner fits neatly in the rest of our cmake code. Change-Id: I75288e97c81b250ac3997f2e7a22bc7bd82b7b69 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: update emscripten to 3.1.10Lorn Potter2022-05-271-1/+1
| | | | | | | | Qt 6.4 will require Emscripten 3.1.10 Change-Id: I34d6288489b6674f6fd75134dd1855ae931c79c2 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* CMake: Use the PRODUCT_NAME for the iOS display name like qmakeAlexandru Croitor2022-05-201-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 Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix issue with linking against static library on iOSAlexandru Croitor2022-05-201-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 Pick-to: 6.2 6.3 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>
* CMake: Automatically use Xcode generator in qt-cmake + iOSAlexandru Croitor2022-05-201-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. Pick-to: 6.2 6.3 Fixes: QTBUG-100834 Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: set correct COMPILE_PDB_NAME for static librariesLi Xinwei2022-05-204-12/+19
| | | | | | | | | | | | | | | Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add option to not include native libraries in APKTinja Paavoseppä2022-05-201-0/+18
| | | | | | | | | | | | | | | | | Sometimes it is not desirable to include the libraries in the APK, e.g. system and vendor apps could prefer having one set of libraries installed on the device. If unbundled deployment is specified, native libraries will not be included in the APK. With unbundled deployment, optional arguments can be passed to set the path to load the libraries on the device. [ChangeLog][Android][Deployment Changes] Adds option for Unbundled deployment, where native libraries are not packaged in the APK. Task-number: QAA-771 Change-Id: Ica51ef83a24dad58c7586bf610a58abe21fc1100 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Avoid using add_custom_command with PRE_LINK for version scriptAlexey Edelev2022-05-191-6/+19
| | | | | | | | | | | add_custom_command with PRE_LINK doesn't work correctly with Multi-Config builds. The better solution is to introduce a custom target that generates the final version script and link the target to the library target as the dependency. Change-Id: Ib7420af752a6a46f29f411f9f0dc8557410b4f22 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix line endings of wrapper scriptsJoerg Bornemann2022-05-172-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 Pick-to: 6.2 6.3 Change-Id: I1603add46f276a5d91bbf0f103a261cdd84c343b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-162-76/+4
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix static library link order when using qmakeAlexandru Croitor2022-05-122-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 Pick-to: 6.2 6.3 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>
* Use full file path for the generated dbus filesAlexey Edelev2022-05-121-2/+8
| | | | | Change-Id: Idb7cb49800eaef4a2e09d3e03d2e44528d992d75 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: enable WASM_BIGINTMorten Sørvig2022-05-121-1/+2
| | | | | | | | | | | | | | | | | | | JavaScripts's BigInt feature provides support for arbitrary-precision integers. This makes it possible to represent 64-bit integers; the standard JS Number type supports 32-bit integers only (or more accurately 53-bit integers - see Number.MAX_SAFE_INTEGER). Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t to BigInt when interfacing with JavaScript code. This removes one of the conditions which enables wasm-emscripten-finalize. Task-number: QTBUG-103352 Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: David Skoland <david.skoland@qt.io>
* wasm: set ASSERTIONS level to default (1)Morten Sørvig2022-05-121-1/+0
| | | | | | | | | | This removes one of the conditions which enables wasm-emscripten-finalize. Task-number: QTBUG-103352 Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* Hardcode atomic_LIB as -latomicDmitry Shachnev2022-05-121-1/+1
| | | | | | | | | | | | | find_library does not always work because libatomic.so may be in a path like /usr/lib/gcc/x86_64-linux-gnu/11/libatomic.so, which CMake does not consider by default. Pick-to: 6.3 Change-Id: I73a657c470efa4f84f8629bd531edfcac3b3a352 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Handle strip wrapper creation more robustlyAlexandru Croitor2022-05-111-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 Pick-to: 6.2 6.3 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>
* CMake: Fix initialization of QT_BUILD_TOOLS_BY_DEFAULTJoerg Bornemann2022-05-112-7/+8
| | | | | | | | | | | | | | ...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON. When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set QT_FORCE_BUILD_TOOLS. But this happened too late: after the initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on QT_FORCE_BUILD_TOOLS. This amends commit acfbe3b7795c741b269fc23ed2c51c5937cd7f4f. Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make possible building Qt tools without the use of core libraryAlexey Edelev2022-05-063-19/+25
| | | | | | | | | | | | | | Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: also allow building tools when found elsewhere in host buildsThiago Macieira2022-05-045-26/+48
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, this was only supported when cross-compiling, but that's an unnecessary limitation. Instead, make it possible to build the "host" tools (notably qmake) even when they've been found elsewhere due to QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH. The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to ON is useful for developers who touch content that ends up in the bootstrap library. QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of QT_FORCE_BUILD_TOOLS. [ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from a host Qt even for a non-cross build and still build the tools. Fixes: QTBUG-99683 Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 15:00:21 +0000