summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Allow opting out of global target promotionAlexandru Croitor2020-08-131-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The endless saga of fighting with qt_find_package and global target promotion. In certain scenarios we want to opt out of target promotion to global scope. One such case is in qttools with WrapLibClang and Threads::Threads. Threads::Threads will be found in the top-level scope via Qt6Dependencies. WrapLibClang is declared in src/ directory scope, and then we try to promote it ands its dependencies to the global scope, via qt_find_package() -> qt_find_package_promote_targets_to_global_scope(). This fails because we can't promote Threads::Threads due to it being added in a different subdirectory scope. Introduce 2 new functions. qt_internal_should_not_promote_package_target_to_global and qt_internal_disable_find_package_global_promotion. The first one is used to disable promotion of targets to global scope in qt_find_package. To mark a target not to be promoted, the second function is used. It will be used by qttools for the WrapLibClang case. Task-number: QTBUG-85877 Change-Id: If6caf10a94999402026517a623ae29e3ab1eeb7f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Extend configure-cmake-mapping.mdJoerg Bornemann2020-08-131-44/+36
| | | | | Change-Id: Ie54b131c9a7b0f560fa735562fc4cbae4df35a49 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow specifying a sysconfdir that's outside the prefixAlexandru Croitor2020-08-131-10/+17
| | | | | | | | | Also use the value to actually write it into qconfig.cpp so that qmake reports the right information. Change-Id: Icc4bf36b0dc6ad75d93ac16f39e5b361c0ce52b4 Fixes: QTBUG-81289 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix empty value of CMAKE_SIZEOF_VOID_P when looking for toolsAlexandru Croitor2020-08-132-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our initial approach to looking for host Qt tools when cross-compiling to a platform with a different architecture bitness compared to the host one was to unset CMAKE_SIZEOF_VOID_P before calling find_package(Qt6FooTools) and then restoring the value. That works to bypass the architecture bitness test in the ConfigVersion files, but it also influences the paths that find_package() searches in, specifically the lib<arch> paths like /usr/lib64 will not be searched in. Fortunately since CMake 3.14, write_basic_package_version_file() can take an additional ARCH_INDEPENDENT parameter. This disables the architecture bitness test when looking for the package, while allowing to still search in the /usr/lib64 like paths. Use it when creating the QtFooToolConfigVersion.cmake files. One could argue we should actually check if the tool executables could run on the host system where find_package is called for cross-compilation. We could do that in another change if the problem ever arises. Amends 03aa74e40d8f1270e1bb28d0791e5bc376ffa0b7 Amends 914b367c7f6a117130b8a56338c46a8102a1f77f Change-Id: I1181ff637ac80064a6a8538170b28a41743fc90c Fixes: QTBUG-81672 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce QtFeatureCommon.cmakeJoerg Bornemann2020-08-133-10/+12
| | | | | | | | This file provides common feature-functionality is supposed to be included by QtFeature.cmake and QtProcessConfigureArgs.cmake. Change-Id: Ifb483c2a9c4014d240c2a4d6ff07b5c0ceee9c3a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.priJoerg Bornemann2020-08-131-0/+2
| | | | | | | | | | | | | If the user specified CMAKE_OSX_DEPLOYMENT_TARGET=10.15 for the Qt build then building projects with qmake failed, because the mkspec hard-codes QMAKE_MACOSX_DEPLOYMENT_TARGET to 10.14. We now write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.pri to override the mkspecs' default. Fixes: QTBUG-85923 Change-Id: I6a39cfe047ac0f99e1da0ca0728d63c741bd4fed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add missing newline at the end of qconfig.priJoerg Bornemann2020-08-131-1/+1
| | | | | Change-Id: I929d74234b685bf0684d3067f7f958d474df20ff Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Suggest qt-cmake-private script for building other Qt modulesKai Koehne2020-08-121-2/+2
| | | | | | | | This automatically sets the CMake Generator to be the same as the one used for qtbase. Change-Id: If9e1a6942520417393055c572f0d892efca43d2e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix Threads::Threads dependency handling with CMake < 3.18Alexandru Croitor2020-08-122-0/+22
| | | | | | | | | | | | | | | | | | | | Apparently CMake encods targets from different scopes with a different encoding scheme for earlier CMake versions. CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50> CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@ Handle the earlier version approach as well. It needs to be done both when writing out 3rd party dependencies, as well as for lib prl files. Possibly in more places as well, but I didn't detect additional places yet. Amends 92ee9bd6b885879090ba57e49c8bd84a06d42b2b Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* cmake, README: clearify the usage of '-' in feature namesRichard Moe Gustavsen2020-08-121-1/+2
| | | | | | | | | | It's not immediately obvious that you need to use all underscores for the feature name, so add a line that explaines it. Change-Id: I508eaf909c808fb0a93442f6e71428c18559b965 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Expose public info about whether Qt is a shared lib buildAlexandru Croitor2020-08-121-0/+1
| | | | | | | | | | We expose it in the private QtBuildInternals package, but we need it also as public information for consumption in qt_import_qml_plugins() to decide whether it should do anything. Change-Id: If135ae596b4edaf8e2c458f6a2518b968c6d01c4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Prepare ground work for static Qml plugins importingAlexandru Croitor2020-08-124-16/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: pro2cmake: Specify library versions for 3rd party libs part 2Alexandru Croitor2020-08-101-1/+6
| | | | | | | | | | Embed package versions into the qt_find_package calls for various Linux specific packages. Task-number: QTBUG-82917 Change-Id: I5d1cb623f81932dfae4658b8a3a89eedb71ea3af Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: pro2cmake: Specify library versions for 3rd party librariesAlexandru Croitor2020-08-106-69/+136
| | | | | | | | | | | | | | | | | | | | | | | | If certain 3rd party libraries have a version that's not suitable for Qt, the configure summary should say so, rather than use them and fail at build time. With the current situation, we have to duplicate the version information from the configure.json files in helper.py, by assigning the version number as an extra find_package variable. Rerunning configurejson2cmake then embeds this version info into the qt_find_package calls in configure.cmake. Some of the Find modules are rewritten to take the specified version into account when looking for the libraries. This involves moving around the code for creating a target, after calling find_package_handle_standard_args() so we know if a good enough version was found. Task-number: QTBUG-82917 Change-Id: I139748d8090e0630cda413362760034dc3483e11 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* configure: Explicitly enable float-divide-by-zero with ubsanRobert Loehning2020-08-071-1/+1
| | | | | | | | | | Before clang 9, it was enabled by default when -fsanitize=undefined was set. Pick-to: 5.15 Change-Id: I0faf3ae1901d4badc6d265fa8081185be4360636 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QDecompressHelper: Add brotli supportMårten Nordheim2020-08-061-0/+43
| | | | | | Task-number: QTBUG-83269 Change-Id: If23b098ee76a4892e4c2c6ce5c635688d8d9138d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* CMake: Don't use lld linker for Android with a Windows hostAlexandru Croitor2020-08-061-1/+4
| | | | | | | | | | | | Most of the time lld just gets stuck (deadlock) waiting on some mutex, thus failing integrations. Amends 64c111e10fcb2f69855432177d76649b6b789fac Task-number: QTBUG-85911 Change-Id: Id73bf967a7aeb0e0cbccfaafe056b325c8711f82 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix prl files of static Qt buildsAlexandru Croitor2020-08-062-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Static Qt plugins should not be included in the list of libraries of a prl file. They end up being there due to our circular dependency trick where the plugins depend on the module they belong to. This in turn causes the giant static plugin generator expressions to be processed in qt_collect_libs(), and the generated prl file ends up having target names like Qt6::QJpegPlugin which are obviously not linker flags. To eliminate the static plugins from prl files, add an additional dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>' that always evaluates to true. We can string match on this expression in qt_collect_libs, and thus remove the whole static plugin genex entry. This should fix linking of apps with qmake that use a CMake-built static Qt. Task-number: QTBUG-85865 Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-065-1/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix build with custom INSTALL_INCLUDEDIRJoerg Bornemann2020-08-063-14/+13
| | | | | | | | | | | | | The include directory in Qt's build directory is always named "include", no matter what the value of INSTALL_INCLUDEDIR is. The main reason is that the name "include" is hard-coded in syncqt. The INSTALL_INCLUDEDIR variable must only affect the installation location of headers. Fixes: QTBUG-85893 Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't build debug tools by default in debug_and_release buildsJoerg Bornemann2020-08-052-0/+10
| | | | | | Fixes: QTBUG-85411 Change-Id: Idd9664d1a9143c31f28549a72823a82df1cff7ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't use std=gnu++11 when building Qt internal targetsAlexandru Croitor2020-08-052-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic is a bit involved in qmake. The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies to qt modules, qt plugins, qml plugins, qt helper libs, winmain and qt_apps, qt_tools, but NOT tests (which is important because the tests on Windows MinGW fail to build without the GNU extensions). Then default_post.prf checks for the strict_c++ value and either uses the strict or non-strict C++ standard flags. default_post.prf is loaded for all qmake projects, not just the Qt internal ones. Now CMake doesn't provide a transitive based option to disable C++ GNU extensions with a mechanism similar to target_compile_features. It only provides the CXX_EXTENSIONS property and it's associated CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a directory scope, because that is too coarse grained. So we rely on setting the property via a function in every relevant qt_add_<target> function. Now the naming of the function is weird. We name the function as qt_internal_<...>, because it's not meant to be used by Qt users. We prepend an underscore to the name because we need to place it in Qt6CoreMacros, so that the function can be called by qt_add_qml_module which IS a public function. That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 + CMake we decided to make qt_add_qml_module() as public API. Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't generate prl libs for Windows shared libsAlexandru Croitor2020-08-041-7/+15
| | | | | | | | | | | | | Windows shared library prl files should not have a QMAKE_PRL_LIBS section. Such information is not useful because it's not used by the linker as per 523c7e3fd55c853dd424d57f28e225d57439cf89 Amends 46d7abc9172f82756ccd3641a314dcc066353c3f Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QtCore: Use system-wide libb2 if presentLinus Jahn2020-07-311-0/+7
| | | | | | | | | | | | This adds the option to build Qt with libb2, which is especially recommended, if you care about the performance of the BLAKE2 hashing algorithms. The bundled version is the pure reference C implementation of BLAKE2, while libb2 has many additional hardware optimizations. However, the API of both is the same, so no changes to the code were necessary here. Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated content of prl files (again)Alexandru Croitor2020-07-315-92/+131
| | | | | | | | | | | | | | | | | | | | | | | | | Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Introduce qt_internal_add_appAlexandru Croitor2020-07-314-9/+149
| | | | | | | | | | | | | | | This new function is meant to be used where load(qt_app) is used. It delegates functionality to qt_add_executable, while handling some additional behavior via a finalization function (mostly handling of macOS Info.plist files and icons, as well as Windows icons and resource files) It uses a new PlatformAppInternal interface target. Task-number: QTBUG-85757 Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix building debug apps with qmake on WindowsAlexandru Croitor2020-07-292-36/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our CMake build system only generated working .prl files for the Release configuration in debug_and_release. This caused a linking failure when building a Widgets example that links against qtmain, specifically qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external symbol __imp_CommandLineToArgvW referenced in function WinMain The symbol is located in shell32.dll, which was not linked in, because there was no qtmaind.prl file. The fix to generate per config prl files is a bit complicated, because add_custom_command does not support generator expressions in OUTPUT and DEPENDS. Instead we pre-generate 2 files per config, one with the preliminary prl file content and another file that contains the final prl file path (via generator expression). Then we iterate over all configurations and create custom commands with well known paths, and the final prl file is created by the script called by the command. Amends 06557312d2a030f9ff771488bd6c97690a125a3d Task-number: QTBUG-85240 Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix _nolink targets to be optional on the consumer sideAlexandru Croitor2020-07-291-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, if Qt is built with Vulkan support but the user's machine does not have Vulkan, it should still be possible to configure and build an application (if the application does not use Vulkan of course). When Qt is built with qmake, the special windows_vulkan_sdk.prf file makes sure not to export build time Vulkan include headers into the generated .pri files. The same file also tries to find the include headers via an environment variable. If it isn't set, it just adds a bogus "/include" include path, which doesn't fail a user's application build. This wasn't the case for an application built with CMake, because the exported Vulkan_nolink target uncodinitionally referenced Vulkan's target properties. Which means that if the Vulkan package was not found, the application failed to configure. To mimic qmake's behavior, make sure to query the target properties only if the Vulkan target exists, via the TARGET_EXISTS generator expression. Apply the same logic to all _nolink targets. This might not be entirely correct in all cases, but we can revise this behavior later after more feedback. At the very least it allows building non-Vulkan based applications. Task-number: QTBUG-85240 Change-Id: Iffbb03a84e8637ed54d0811433e66fe6de43d71f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* cmake: Add some air to configure summaryTor Arne Vestbø2020-07-261-4/+3
| | | | | Change-Id: I3408957d8a81ac3080eac28e48dbafe9059e22f5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make missing XCode a warning instead of an errorAlex Richardson2020-07-261-1/+1
| | | | | | | | This fixes the macOS build when you only have the CommandLineTools installed. Change-Id: I620bc535b508b604a875f53dec8c57af23efeac1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cmake: Add LOWDPI option to match CONFIG+=testcase_lowdpiTor Arne Vestbø2020-07-241-1/+9
| | | | | Change-Id: I8bcabf41ed353ec4e940a8fcea5b698e0ddf278f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATHAlexandru Croitor2020-07-244-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to implement the 'host artifact reuse' Coin instructions change, a bug surfaced where the qemu configurations didn't find the host tools and instead tried to use the cross-compiled tools while building qtbase, which failed due to not finding the runtime linker (another unsolved issue). Before the host artifact reuse change, the host tools were found successfully. The difference that caused the issue is that the target install prefix was a direct subfolder of the host prefix. host - /home/qt/work/qt/install target - /home/qt/work/qt/install/target Before the host reuse change the install prefixes were as follows host - /home/qt/work/qt/install/host target - /home/qt/work/qt/install/target While looking for the Qt6CoreTools package, we temporarily set CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first '/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'. CMake then reroots the CMAKE_PREFIX_PATH values onto values in CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search. Rerooting essentially means concatenating 2 paths, unless the considered prefix is a subfolder of the root path. What happened was that the first considered value was '/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent location that gets discarded. The second considered value was '/home/qt/work/qt/install/target. The second value is the result of seeing that '/home/qt/work/qt/install/target' is a subfolder of '/home/qt/work/qt/install' and thus the root path is stripped. All of this is done in cmFindPackageCommand::FindConfig() -> cmFindCommon::RerootPaths. The behavior above caused the target tools be found instead of the host ones. Before the host reuse change, both of the initial constructed prefixes were discared due to them not existing, e.g. '/home/qt/work/qt/install/target/home/qt/work/qt/install/target' and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host' One of the later prefixes combined CMAKE_FIND_ROOT_PATH == '/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting in '/home/qt/work/qt/install/host/' and this accidentally found the host tools package. We actually stumbled upon this issue a while ago when implementing Qt 5.14 Android CMake support in 52c799ed4425076df4353c02950ea1444fe5f102 That commit message mentions the fix is to add a "lib/cmake" suffix to the PATHS option of find_package(). This would cause the subfolder => strip root behavior mentioned above. So finally the fix. First, make sure not to append QT_HOST_PATH in the toolchain file, there shouldn't be any need to do that, give that we temporarily set it when looking for Tools packages. Second, recreate the subdir scenario in the Qt toolchain file by setting CMAKE_FIND_ROOT_PATH to the current (relocated) install prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value poining to the CMake directory. Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'. Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host equivalents of the target ones above. Use these values when looking for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing the subdir behavior. Note these are currently absolute paths and are not relocatable. We'll have to figure out if it's even possible to make the host path relocatable. Finally as a cleanup, look for the Qt6HostInfo package in QtSetup strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find a system Qt package. Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add -Wsuggest-override for gcc >= 9.2Alexander Volkov2020-07-241-0/+4
| | | | | | | | | gcc doesn't report warnings for final methods since version 9.2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010 Change-Id: I7152351aac0e3bad86d777e119f25137ef97ec6f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Avoid enabling of "warnings_are_errors" flags for testsAlexander Volkov2020-07-231-1/+1
| | | | | | | | Change added dep in qt_add_cmake_library(): PlarformModuleInternal -> PlatformCommonInternal. Change-Id: I303a6a520f0dda7260b12cb21673b8f1a23d536b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* testlib selftest: Don't pass TESTARGS to Catch2Tor Arne Vestbø2020-07-231-2/+6
| | | | | | | It doesn't understand the arguments we usually pass to testlib. Change-Id: Iea83d1d8c31a510b2bc442cbfc810eac631322e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Print various CMake and Qt CMake information variablesAlexandru Croitor2020-07-202-9/+90
| | | | | | | | | | | Sometimes the info we show in the configure summary might differ from the information that CMake computes. To more easily debug and fix such cases, print out various CMake info variables like host and target info, compiler versions, sdk versions, etc. Change-Id: I37a11dfabe5369236af78684a09bd3cec3fdd398 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Pass CMAKE_OSX_ARCHITECTURES to try_compile on macOSAlexandru Croitor2020-07-201-9/+11
| | | | | | | | | | | | | | | | | | | | There was an inconsistency where configuring qtbase on Apple Silicon with the following command line produced different results rom the second variant. $ cmake ../qtbase -DCMAKE_OSX_ARCHITECTURES=arm64 vs $ CMAKE_OSX_ARCHITECTURES=arm64 cmake ../qtbase That happened because the CMAKE_OSX_ARCHITECTURES variables was not passed to project-based try_compile calls. This resulted in compile tests like SIMD avx to succeeded on Apple silicon, which shouldn't. To address that, always pass the architecture on macOS if it's specified. Change-Id: Ia12e86230cc6e5e11f387e3cbb273d90646ef2e3 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix configuration of CMake tests in-build-treeAlexandru Croitor2020-07-201-5/+11
| | | | | | | | | | | | Qt6 package was not found the tests were configured in-tree as opposed to standalone tests. Use the same trick we do for building examples in-tree. Specify the path to the build tree packages, and don't create targets. Amends 96e3ee06598d00e7155f3f8574759ea658a134e5 Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Provide old style CMake variables for target infoAlexandru Croitor2020-07-173-0/+62
| | | | | | | | | | | | | | | | | | | | | This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix old style find_package(Qt6Foo) to workAlexandru Croitor2020-07-172-1/+16
| | | | | | | | | | Each module package needs to first find the Qt6 package to ensure that all the necessary info is setup for further depedencies to be found. Task-number: QTBUG-81672 Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add OS-specific prelude to qt-cmake-standalone-testJonas Karlsson2020-07-151-0/+2
| | | | | | | | | | | | This makes sure the executable is run as a shell script with the proper interpreter on Unix systems. Otherwise it will fail in some shells, like fish. On windows, it prevents all commands in the batch file from displaying on the screen. Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix QT_STAGING_PREFIX for repos other than qtbaseJoerg Bornemann2020-07-133-2/+18
| | | | | | | | | | | | | For repositories other than qtbase the QT_STAGING_PREFIX was empty, because it was only determined in qtbase. Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package and set this variable if it's not explicitly set by the user. As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON. Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix CMAKE_INSTALL_PREFIX assignment in QtBuildInternalsExtraJoerg Bornemann2020-07-131-1/+1
| | | | | | | | The prefix value must be surrounded by double quotes in case it contains whitespace. Change-Id: I393c57368d7a255f5042e363405071ef042afc18 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix incorrect SIMD arch_haswell and avx profile conditionsAllan Sandfeld Jensen2020-07-092-5/+41
| | | | | | | | | | | | | | | | | | | | Fix the conditions in qt_add_simd_part for arch_haswell and the avx512 profiles to mimic what simd.prf does. Add missing SIMD flags in QtCompilerOptimization for arch_haswell. Compute the compile flags for the avx512 profiles from the profile dependencies. Remove the special case in Gui that hardcoded the compilation of qdrawhelper_avx2.cpp to be conditional on avx2 being enabled instead of arch_haswell. The Gui project already has another qt_add_simd_part that is enabled if arch_haswell is enabled, which will now work correctly due to the fixes in qt_add_simd_part. Change-Id: I7a61a03b5565d4fa438f22b329e0d9dd7acd9273 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix various issues with the Android buildAlexandru Croitor2020-07-091-2/+1
| | | | | | | | | | | | | | | | | | | Certain resources and compiled jar files have to be copied into the non-prefix build dir location. They were previously only installed, which doesn't do anything in a non-prefix build. Change pro2cmake to generate code that places the compiled java jars into QT_BUILD_DIR, so that non-prefix builds work. Place the module dependencies xml files into lib folder in non-prefix builds. Don't special case the output and install location of the Android QPA plugin. Task-number: QTBUG-85399 Change-Id: I4ac9d3929ea8ecc95ec99a77e621ad2121b68832 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix missing qdevice.pri values and qt.conf info for AndroidAlexandru Croitor2020-07-092-3/+30
| | | | | | | | | | | | | | | | qdevice.pri should embed info about the Android SDK, NDK, host, platform api level and ABI. The machine tuple test should not be run for uikit and Android platforms. Sysroot should also not be prepended for uikit and Android platforms, otherwise it breaks Qt module include paths. Task-number: QTBUG-85399 Task-number: QTBUG-82581 Change-Id: Ic48c88f6ab15d75c2ebc323c8d7a3b7e5596f3c1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix path to qt-cmake in configure summaryJoerg Bornemann2020-07-091-1/+1
| | | | | | | The path was wrong if CMAKE_STAGING_PREFIX was set. Change-Id: Iec90c7a5edf0da80a0ac108fe3411c340c01e9a9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix qt-cmake-standalone-test when CMAKE_STAGING_PREFIX is setJoerg Bornemann2020-07-091-3/+3
| | | | | | | | | | The qt-cmake-standalone-test script is kind of a "host tool" and contained paths to CMAKE_INSTALL_PREFIX, which is wrong if CMAKE_STAGING_PREFIX points to somewhere else. Fixes: QTBUG-85336 Change-Id: I4828dc6868d55cfc60f3ad2199185230d5cc9028 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Introduce QT_STAGING_PREFIXJoerg Bornemann2020-07-092-10/+4
| | | | | | | | | | | Add the cache variable QT_STAGING_PREFIX that is the same as CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise. Use the variable in the places where we check for the emptiness of CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX. Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix -pch configure optionJoerg Bornemann2020-07-081-1/+1
| | | | | | | This amends dbd3c759654. Change-Id: Ia87d60f1da65624bc5c6ffb915eecf99a2d8bdc0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-03 21:51:05 +0000