summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Override simulator architecture to x86_64 for Xcode generatorTor Arne Vestbø2022-08-031-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. Pick-to: 6.4 6.3 6.2 Change-Id: I8b52389db1b83f4f9679c724bcde53b44dbc76f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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 Pick-to: 6.2 6.3 6.4 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-03133-4/+399
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-95834 Change-Id: I992bd61024958869f3b995471b4c7ff75e3a33a0 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove internal __qt_add_plugin_*_args variablesJoerg Bornemann2022-08-031-37/+0
| | | | | | | | All references to these variables have been removed from Qt repositories. Change-Id: Icca4668ec183ff543d04097600f8a8869066f8cc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Build minimal subset of tests for Android multi-ABI Qt buildsAlexey Edelev2022-08-023-1/+5
| | | | | | | | | Add an option to limit the number of tests for building and testing Android multi-ABI configurations in CI. Currently only Core tests supposed to run. Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Deprecate _add_app/executable/test/tool PUBLIC_LIBRARIES optionAlexandru Croitor2022-07-294-9/+46
| | | | | | | | | | | | | | | | | | | | | | | Warn projects not to use it because PUBLIC_LIBRARIES don't make sense for executable targets and it also led to some issues in the internal functions where some of them did not expect to receive PUBLIC_LIBRARIES. To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values as regular LIBRARIES. In the future we might add an error instead. Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally worked because the option name and the values following it were parsed as values of the "previous" option, like SOURCES or INCLUDE_DIRECTORIES or LIBRARIES, and when those got passed through to qt_internal_extend_target, things magically worked. We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the way qmake pro files were written and how pro2cmake converted them. We'll have to clean up each repo. Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* cmake: add support for EXCEPTIONS to qt_internal_add_appRobert Griebl2022-07-281-1/+7
| | | | | Change-Id: I79088f6647496ed455573cab9d403bd8a3f26c76 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Export package name and 3rdparty flag for 3rd party librariesAlexandru Croitor2022-07-281-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | Needed to get rid of warnings like CMake Warning at cmake/QtFindPackageHelpers.cmake:406 (message): Could not find target Qt6::BundledLibYaml to query its package name. Defaulting to package name Qt6BundledLibYaml. Consider re-arranging the project structure to ensure the target exists by this point. which were introduced with the integration of dffcc2370e43722afb25d7aec7cd9d6a36f61e03 in qtbase. This happened because we never set and exported the package names for 3rd party bundled libs. So export the package name as well as "is 3rd party lib" value. Amends 6235f7fa62aab5c0e002fa2f93f46508f38b5472 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I25fc1ffef766198974025e0097bced1cca4dd28d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Mark PlatformCommonInternal as a Qt6 packageAlexandru Croitor2022-07-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add PlatformCommonInternal to the list of packages compared in qt_internal_is_lib_part_of_qt6_package It gets rid of the following warnings when configuring standalone tests CMake Warning at cmake/QtFindPackageHelpers.cmake:406 (message): Could not find target Qt6::PlatformCommonInternal to query its package name. Defaulting to package name Qt6PlatformCommonInternal. Consider re-arranging the project structure to ensure the target exists by this point. CMake Warning at cmake/QtFindPackageHelpers.cmake:374 (message): Could not determine package version of target PlatformCommonInternal. Defaulting to project version 6.5.0. Amends 606124c5cceba0dd4a406a9278588b58bb9f9800 Amends dd1030a4501ca067e96f50085c8cfda19d85afd4 Amends dffcc2370e43722afb25d7aec7cd9d6a36f61e03 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I65c23c20b3c1b70dbfd54edd4f5b83c6781f5e6f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix install destination of in-tree examplesAlexandru Croitor2022-07-271-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 Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-102879 Change-Id: Id47e3ce06faec6d156ae1473942dae0f9b90cb46 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add per-target support for iOS launch screensAlexandru Croitor2022-07-272-2/+2
| | | | | | | | | | | | | | | | | | | | | | | To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Add shared library plugin names to the QT_PLUGINS propertyAlexandru Croitor2022-07-271-4/+6
| | | | | | | | | | | | | Otherwise we don't create a Qt6FooPlugins.cmake file in shared Qt builds. Adjust comment. Amends f68e2c92cc0ed2c1929140402c061359bc2363a5 Related to 7d6f1ee5a75cae9d122a3f0c7b3a6d03f380535e Change-Id: I9c66d81197a4867039d5c53daf1b7edf0391c701 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* 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 Pick-to: 6.2 6.3 6.4 Change-Id: I6692a76e0491a1c5e28982aa5fbe8b8aec8dec56 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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 Pick-to: 6.2 6.3 6.4 Change-Id: Ib7bc87f07e195125c858dcece2df6e82303dd01c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Change __qt_internal_include_plugin_packages to be a macroAlexandru Croitor2022-07-251-25/+28
| | | | | | | | | | | | | | | | | | | The __qt_internal_include_plugin_packages function includes PluginConfig.cmake files which in turn might look for dependencies with find_dependency. The dependencies that were found not have their _FOUND variables set in the calling scope, which could cause multiple lookups of the same dependency packages. Change the function to be macro, so that all relevant _FOUND variables are set and no unnecessary package lookups are done. As a result, no need to set the QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE variable using set(PARENT_SCOPE) Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Iba0fc83d9e58651f095e7b70d1ed19f064c4e577 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't look for Qt6 components that are already foundAlexandru Croitor2022-07-251-11/+13
| | | | | | | | | | | | | | | | This matches what we do in Dependencies.cmake files, except this time for COMPONENTS passed to the Qt6 package. For example if a project does find_package(Qt6 COMPONENTS Widgets Core) we'd end up looking for Core twice. Once as a dependency of Widgets and once as a standalone request of the project. Make sure to skip the second lookup if it was already found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I61db7fbb99818b4b70a0bfe3e167b6f14732292e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't unset Qt6Qml_FOUND when including Qml pluginsAlexandru Croitor2022-07-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | Removing the variable would cause nested find_dependency calls of FooQmlPluginDependencies.cmake files to look for the Qml package again and again. If we got to the point of including QmlPlugins.cmake, we already know that the Qml package was found. Set it to TRUE after every inclusion to avoid repeated Qml package loading. The second inclusion pass will ensure to set the found variable to FALSE in case if some dependency is actually missing. Amends aad4158959890b72afdd062614c1142c100c65b5 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Record the precise package name where Private modules liveAlexandru Croitor2022-07-253-13/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if a target depended on CorePrivate, we would write a _qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a FooDependencies.cmake file. That find_qt_deps call would remove the 'Private' suffix and would run find_dependency with NAMES set to both the altered and non-altered names. This would find the relevant package but it would set the wrong _FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead of Qt6Core_FOUND. This in turn could cause multiple lookups of the Qt6Core package during dependency handling because the correct _FOUND var would not be set. Instead of always looking for the Qt6CorePrivate package, make sure we look for an appropriately named package for all Privates modules, because we have the necessary info to determine the correct name. Note that INTERNAL modules will still be looked up via a Private suffixed package name because that's how the package name is chosen for them. Remove the code that accounted for Private modules in qt_internal_remove_qt_dependency_duplicates because it's not needed anymore. Warn when a package name can't be queried from a target's property because the target might not exist yet. Add a TODO comment for the code that searches with two NAMES. We can't remove it right now, because it might break user projects that use stale Dependencies.cmake files. The dbus subdirectory is added before the tools subdirectory to ensure that the new package name extraction does not error out, due to trying to access a target that does not yet exist. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Create aliases for Internal targets using common functionAlexandru Croitor2022-07-251-5/+5
| | | | | | | | | | | | | | | | | | | Previously we did not create Qt6:: namespaced aliases. This is needed as a workaround preparation for getting the package name of a module target from one of it's properties. Before it would fail in qtinterfaceframework because ifvehiclefunctions-simulation-server uses PUBLIC_LIBRARIES in its qt_internal_add_app call, and because _add_app does not handle such an option, some weirdness in qtbase's _add_app -> _add_executable -> _extend_executable -> _register_target_dependencies ended up trying to register PlatformAppInternal as package dependency. That issue will be handled in separate changes. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ifd03528c95b08cb6837a6aaa26cbf97c0cbabbb4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Export a few useful Qt module target propertiesAlexandru Croitor2022-07-251-5/+37
| | | | | | | | | | | | | | These include: _qt_package_name _qt_is_public_module _qt_is_private_module _qt_public_module_target_name _qt_private_module_target_name Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I012463944de8fc333f477a7880f9d27a69d6ef47 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't repeatedly look for the Qt6 dependencyAlexandru Croitor2022-07-251-8/+11
| | | | | | | | | | | | When loading Qt packages, don't look for the Qt6 dependency if it was already found in the given subdirectory scope. This reduces the amount of find_dependency(Qt6) calls. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I737c4433daf30eed51a058b45cd539dff7657ca4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move QT_HOST_PATH check and computation into Qt6 packageAlexandru Croitor2022-07-255-87/+90
| | | | | | | | | | | | | | | | Instead of trying to compute and validate the QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file, do it in the Qt6 package. This provides better error messages when a project is configured without using the Qt generated toolchain file. Because it's not done in the toolchain anymore, remove the various host variables from __qt_toolchain_used_variables. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Improve Qt6HostInfo package lookup conditionAlexandru Croitor2022-07-254-4/+16
| | | | | | | | | | | | | | | | | | | Instead of checking if QT_HOST_PATH is set during user project configuration to find out if Qt6HostInfo should be looked up, record if QT_HOST_PATH was provided during Qt configuration into Qt6Dependencies.cmake and look up the package in a user project based on that information. This improves handling of the case where cmake is directly used to configure a Qt project (instead of qt-cmake), which means no QT_HOST_PATH might be set by the user, and then cmake would error out saying that e.g. Qt6CoreTools is not found, instead of saying that Qt6HostInfo is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move Qt6HostInfo lookup into a functionAlexandru Croitor2022-07-255-27/+24
| | | | | | | | | | | | | | | Also replace the duplicate call in QtSetup using the new function. To do that, we have to actually the call it in QtBuild after QtPublicDependencyHelpers.cmake is available. That call is needed so that Qt6_HOST_INFO_foo variables are available in qt_generate_qmake_and_qtpaths_wrapper_for_target. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* cmake: Teach qt_internal_extend_target about PLUGIN_TYPESTor Arne Vestbø2022-07-253-13/+25
| | | | | Change-Id: I2e8a3faa6ada66a644dceeb98f9ba8e994db4192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Link static plugins even in shared Qt buildsTor Arne Vestbø2022-07-251-0/+8
| | | | | | | | | It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Generate prl and pri files for static plugins in shared Qt buildsTor Arne Vestbø2022-07-251-3/+5
| | | | | | | | The CMake build system files are properly generated, but the qmake parts were missing. Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Link static plugins even in shared Qt buildsTor Arne Vestbø2022-07-253-136/+146
| | | | | | | | | | | | | | | | It's perfectly possible to create static plugins in an otherwise shared Qt build, but the logic to import these plugins into applications was assuming a fully static Qt build. We now handle this more granularly. This works for in-source tools and tests as well, which don't go through the same CMake machinery for plugins as user projects do. The only case that does not currently work is in-source examples, as they don't share any of the plugin machinery with neither Qt internal tools/tests or user project, but that's a bigger architectural issue that goes beyond this change. Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* QT_INLINE_SINCE: take version into accountIvan Solovev2022-07-221-5/+13
| | | | | | | | | | | | | | | | | | This patch improves the QT_INLINE_SINCE(maj, min) macro to take deprecation version into account. If the specified (maj, min) version is less than or equal to the version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand to "inline", and the out-of-line fallback will be removed from the library. This is achieved by introducing the helper QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro. Fixes: QTBUG-104131 Pick-to: 6.4 Change-Id: I285029dad7b71126072b024a3be6d7b11341996d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add -Wshorten-64-to-32 to headerscleanTor Arne Vestbø2022-07-211-0/+4
| | | | | | | | Fix existing warnings by casting to the appropriate type. Change-Id: Ic44d2a71e1a2e508199dbb46bea7a19e183ec42c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* CMake: prepend build dir for examples buildSamuli Piippo2022-07-211-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. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: fix the word order in "no_direct_extern_access"Thiago Macieira2022-07-202-2/+2
| | | | | | | | | And take the opportunity to remove the "m" in the qmake feature name and .prf file. Pick-to: 6.4 Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix attempt to use -mno-direct-extern-access with ClangThiago Macieira2022-07-201-1/+2
| | | | | | | | | Clang has the option, but spells it differently. Fixes: QTBUG-105002 Pick-to: 6.4 Change-Id: I36b24183fbd041179f2ffffd170217e82ff6d14d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* MSVC: Fix the CET parametersYuhang Zhao2022-07-201-4/+1
| | | | | | | | | | | | | | | | | | To enable CET for MSVC, only passing "/CETCOMPAT" to the linker should be sufficient. Enabling generation of EH Continuation (EHCONT) metadata is additional protection and should not be necessary. It also requires all the dependencies to be re-compiled with EHCONT enabled, otherwise the linker will refuse to link the obj files. However, this is rather hard to achieve if your application depends on many 3rd-party libraries, so to let people enable CET more freely, we don't enable EHCONT guard by default. Pick-to: 6.4 Change-Id: Iba08a5ec56c474d291991fb751a0de764719bd85 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshootingAlexandru Croitor2022-07-183-4/+59
| | | | | | | | | | | | | | | | | | | | | | | When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Suggest hints on how to debug missing packagesAlexandru Croitor2022-07-186-15/+51
| | | | | | | | | | | | | | | | | | | | | Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Allow setting Qt6_DIR to find packages when not cross-compilingAlexandru Croitor2022-07-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we always recommended that developers set CMAKE_PREFIX_PATH to point to the location of the Qt installation so that Qt packages are found by CMake. In Qt5 one could also set the Qt5_DIR variable to $qt/lib/cmake/Qt5 to allow the following signature to work: find_package(Qt5 COMPONENTS Core) This was not sufficient in Qt6 because the CoreTools dependency would not be found. Fix this by also looking into the parent folder of CMAKE_CURRENT_LIST_DIR as well as _qt_cmake_dir, like we already do for regular non-Tools packages in _qt_internal_find_dependencies. Note that setting Qt6_DIR is not sufficient for cross-compilation if the qt.toolchain.cmake file is not used. Aside from platform specific options that would have to be passed manually to CMake (like -DCMAKE_SYSTEM_NAME=iOS for iOS) and passing a QT_HOST_PATH value, the code would also need to be adapted to do the necessary CMAKE_FIND_ROOT_PATH manipulations to ensure that dependent packages are found. Pick-to: 6.4 Task-number: QTBUG-97615 Change-Id: I10c419632d43bb929e184bab3b9d3d27a35ea87a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Display reason when a Qt*Tools package is not foundAlexandru Croitor2022-07-181-0/+4
| | | | | | | | | | | | | When a package's tools dependency is not found (e.g. Core's CoreTools) set the _NOT_FOUND_MESSAGE variable the same way that find_dependency does. We can't use find_dependency directly because that returns immediately without allowing us to reset the prefix paths vars. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I81e9817de8f30214fafbefe3d98ef7bc8848e715 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't propagate REQUIRED to find_dependency / find_packageAlexandru Croitor2022-07-183-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | If find_package(Qt6 REQUIRED COMPONENTS Core) is called, don't propagate the REQUIRED option to all the dependencies of Core, regardless if it's a 3rd party library, tool or another Qt package dependency. Propagating REQUIRED causes the find_dependency -> find_package call to exit the calling file immediately when the package is not found, not giving an opportunity for find_dependency to set the _NOT_FOUND_MESSAGE variable. Instead force all find_dependency / find_package calls to be optional, set the calling _FOUND variable to FALSE if the dependency is not found, also set the _NOT_FOUND_MESSAGE variable. Then the find_package call that loaded FooModuleConfig.cmake file will show that message as the reason for the package not being found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Idcf0b6ed6f6bb38dc082110bbd817b05e287c052 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Clarify if an optional or required Qt component is not foundAlexandru Croitor2022-07-181-2/+2
| | | | | | | Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Id35f128404eb49a655d52ef130f8acb02f8ed33a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't search for next Qt component if a required one is missingAlexandru Croitor2022-07-181-0/+1
| | | | | | | | | | | | | | | If a project calls find_package(Qt6 COMPONENTS Gui Network) and Gui is not found, there's no reason to look for Network, because the COMPONENTS option implies that it is a required component. Failing to find a component sets Qt6_FOUND to false, so we can break early. If a project calls find_package(Qt6 OPTIONAL_COMPONENTS Gui Network) then Network will still be looked for if Gui is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I5c5edd27729635e6b7ade059656b49320364ad13 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove custom Qt6 3rd party dependency implementationAlexandru Croitor2022-07-182-48/+7
| | | | | | | | | | | | | | | | | | Use _qt_internal_find_third_party_dependencies instead. We rely on the inner find_dependency call to set the Qt6_NOT_FOUND_MESSAGE message when a dependency is not found. This implies removing the custom FATAL_ERROR handling and relying on the parent find_package to display the Qt6_NOT_FOUND_MESSAGE message. We also clear Qt6_FIND_COMPONENTS if a dependency is not found. No need to look for Qt packages if the Qt6 dependency was not met. This reduces the amount of recursive error messages. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I5c611aaededfa63eb507ec5385b37a2fb6fcc698 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename _qt_internal_find_dependencies to something less genericAlexandru Croitor2022-07-183-3/+12
| | | | | | | Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I99b69865f711ff57511f32df2f345cebb7445d44 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Extract package dependency finding into functionsAlexandru Croitor2022-07-183-96/+82
| | | | | | | | | | | | | | | | Aside from moving the code to reduce duplication, the only changes in the code are the replacement of @target@ to ${target}, using IN LISTS with variable names to avoid macro expansion issues and replacing the if(var) conditions with double variable evaluation + NOT STREQUAL "". The function implementations are now in the same order as they are used in the Dependencies.cmake files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Iaae926414fd2a7cc09c2f5716376caaa0aade74b Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove dead codeAlexandru Croitor2022-07-181-1/+1
| | | | | | | | | | | | It was accidentally left when changes were made from patchset 1 to patchset 2 in 825cb50c27fc0942a76771f9fb2ec052dc9142bf Amends 825cb50c27fc0942a76771f9fb2ec052dc9142bf Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I04dd50cfb93655f0c224bb226695e7771e9bc5d1 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Rename the <module>_timestamp target to <module>_pri_dep_timestampAlexey Edelev2022-07-152-2/+2
| | | | | | | Make the target purpose more understandable from its name. Change-Id: I4f4a56fd3ef338b728d4a81edc2df32cada97f6c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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. Pick-to: 6.2 6.3 6.4 Change-Id: Iee66ecea569e7411c6b5a5e5312cde910a48fa01 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix prefix propagation for relocated Qt installationsJoerg Bornemann2022-07-131-7/+6
| | | | | | | | | | | | | | Consider qtbase built with CMAKE_STAGING_PREFIX=/foo on Windows. If /foo was moved to /bar, non-qtbase repositories did get a staging prefix with drive letter assigned. This is undesirable when DESTDIR is used on installation. Change the implementation of qt_internal_new_prefix to remove the drive letter from the "new prefix" if the "old prefix" did not have a drive letter. Change-Id: I6fb17e690b264920b0dd4204e3b3c30794c7e76e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Process extra dependencies for plugin targets as wellAlexandru Croitor2022-07-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We started recording extra dependencies for the QtNetwork TLS plugin, but we never actually processed them to write out the necessary find_package calls. This broke static builds of qtopcua, because the OpenSSL::SSL target was no longer created in the root scope, but only in some child ones like src/opcua, whereas the target was referenced in generator expressions in a different sibling scope src/declarative_opcua, leading to errors like CMake Error at lib/cmake/Qt6/QtPrlHelpers.cmake:116 (file): Error evaluating generator expression: $<TARGET_LINKER_FILE:OpenSSL::SSL> No target "OpenSSL::SSL" Call Stack (most recent call first): lib/cmake/Qt6/QtModuleHelpers.cmake:837 (qt_generate_prl_file) lib/cmake/Qt6/QtScopeFinalizerHelpers.cmake:21:EVAL:1 (qt_finalize_module) src/declarative_opcua/CMakeLists.txt:DEFERRED Make sure to process the extra deps for plugins as well. Amends d754e43721e4f40a8dffa8b69ef883ca383a4a61 Amends 3c233175523a61e734dd5cd9bdcbb2994566f7f0 Pick-to: 6.4 Task-number: QTBUG-96283 Change-Id: I11876e0844198b3a794bc06b6691ee694fd3b1c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 23:10:05 +0000