summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Improve tool not found error messageAlexandru Croitor2022-08-121-3/+16
| | | | | | | Pick-to: 6.4 Change-Id: I7f04e4af80c4d23b855c8c9d5f5017f8afb112ea Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Rename arg_HEADER_MODULE variable to 'is_interface_lib'Alexey Edelev2022-08-121-6/+5
| | | | | | | | | Variables starting with 'arg_' usually are the result of the cmake_parse_arguments call. It's better to not use them for the regular variables for readability. Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not use the HEADER_MODULE argument in qt_generate_module_pri_fileAlexey Edelev2022-08-122-11/+14
| | | | | | | | | | HEADER_MODULE argument is passed to qt_generate_module_pri_file from the qt_internal_add_module function, but the property means that the module is an interface library. So it makes sense to replace this argument with the reading of the target TYPE. Change-Id: I1d8cd2ff732f526975cde6bdd4783fee44c8bd98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: allow apps to override EXPORT_RUNTIME_METHODSLorn Potter2022-08-122-1/+8
| | | | | | | | | | | | | | | | | | | | | | | Developers can add to Emscripten's EXPORT_RUNTIME_METHODS by defining their own using: QT_WASM_EXTRA_EXPORTED_METHODS Which will add on to Qt's default exported runtime methods of UTF16ToString,stringToUTF16 for cmake: set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") or set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap") for qmake: QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap Done-with: Mikolaj Boc Fixes: QTBUG-104882 Pick-to: 6.4 Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Put Qt-internal targets into a dedicated FOLDERJoerg Bornemann2022-08-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | When loading a Qt CMake project in an IDE like Visual Studio, many Qt-internal targets are visible, right next to the user's targets. This is inconvenient and confusing. Use CMake's FOLDER concept, and put Qt-internal targets into a dedicated FOLDER. For that we introduce the new global property QT_TARGETS_FOLDER that, analoguous to AUTOGEN_TARGETS_FOLDER, is the folder name for Qt-internal targets. By default, it's not set, nor is folder support enabled. Change qt_standard_project_setup() to - enable folder support - initialize QT_TARGETS_FOLDER if unset - initialize AUTOGEN_TARGETS_FOLDER to the same value if unset Set the FOLDER property of qtbase's internal targets for user projects to the value of QT_TARGETS_FOLDER. Task-number: QTBUG-99808 Change-Id: I880ac7731f88faa83a384dcdec98b1b88ac6cc2e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove HEADER_MODULE from qt_internal_extend_targetAlexey Edelev2022-08-112-7/+10
| | | | | | | | | | | | | The current qt_internal_extend_target interface expects that the caller will pass the HEADER_MODULE argument on each call. This is not correct, since the argument doesn't affect the target internals, but only help to decide how to modify the target according to its type. The target type meanwhile can be always read from target properties. So this solution is more consistent. Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add the output of qlalr to the consuming target source filesAlexey Edelev2022-08-101-3/+4
| | | | | | | | The qlalr outputs need to be added to the consuming target. Change-Id: I9600729103298cf7e0a712d5f3dc49c5f4c729f5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix detection of system double-conversionJoerg Bornemann2022-08-101-4/+9
| | | | | | | | | | | | | | | | | | | | | | ...if the double-conversion CMake package cannot be loaded. The find_path call must specify the header exactly as it is included. The select_library_configurations call always failed, because the command expects the presence of DOUBLE_CONVERSIONS_LIBRARY_DEBUG, DOUBLE_CONVERSIONS_LIBRARY_RELEASE, or both. Upstream double-conversion's MSVC build system does not specify a naming scheme for the debug build, and there are no debug/release binaries to download that suggest a naming scheme. Therefore we assume the usual 'd' suffix for the debug library like we do everywhere else. Lastly, we need to set DOUBLE_CONVERSION_INCLUDE_DIRS. Fixes: QTBUG-105501 Pick-to: 6.2 6.3 6.4 Change-Id: I71ff5238f353541b8bf5ac6792b86134deba20d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add "content file" mode for the qt_internal_add_linker_version_scriptAlexey Edelev2022-08-093-15/+66
| | | | | | | | | | Add the support of pre-cooked content for the LD version script. The content can be generated without using the perl script at configure or build time. Change-Id: I1316e114a1d5550b2fdcf3482a51f336fb311a29 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the common headersclean_check targetAlexey Edelev2022-08-092-8/+17
| | | | | | | | | | | | | Add headersclean_check that allows to run all module-specific '_headersclean_check' targets in single command. Also add dependency on input header files for the headers clean custom commands. Also adjust the '_headersclean_check' target names to match the naming of module targets - the 'Qt' prefix is removed. Change-Id: I17c3442c3c51ce99cd9b38c85d606e9ababbb013 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Bail when configuring multiple configurations and plain NinjaAlexandru Croitor2022-08-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | Previously configuration would not error out if you configured Qt with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug -GNinja instead you would get an error like CMake Error at cmake/QtBaseConfigureTests.cmake:51 (message): Failed to find compiled architecture detection executable at qtbase/build/config.tests/arch/RelWithDebInfo/architecture_test.exe Note that Qt code tries to find the arch test in a RelWithDebInfo directory but due to using single-config Ninja, CMAKE_CONFIGURATION_TYPES is ignored, and the executable is placed in a non-config specific folder. Error out early in such a case, and mention that for multi-config builds, the Ninja Multi-Config generator should be used. Pick-to: 6.4 Change-Id: I0192185123be563671cbe154f968a03b7458e327 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Remove cmake/FindCups.cmakeJoerg Bornemann2022-08-091-99/+0
| | | | | | | | | All supported CMake versions provide this file, and we did not modify it. Pick-to: 6.4 Change-Id: I4b21a99159ba8315491dc64ab737b7e5a28a6966 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Allow adding extra content to plugin pri fileTor Arne Vestbø2022-08-081-1/+12
| | | | | | | Just like for module pri files. Change-Id: Ie209784f1dbc5db5dcfdef2520bac178734d4894 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Use file instead of qt_configure_file for generating plugin priTor Arne Vestbø2022-08-081-4/+5
| | | | | | | | Matches qt_generate_module_pri_file and allows using genexes in the content of the file. Change-Id: I5ee7a973d3e27a721e31315d3ebe2c88ffa1db42 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Move qt_install call into qt_generate_plugin_pri_fileTor Arne Vestbø2022-08-082-6/+4
| | | | | | | The same way qt_generate_module_pri_file does it. Change-Id: I42047ce7d23e8a289535041ccace8b0f0140ea12 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Defer generating plugin .pri file until finalizerTor Arne Vestbø2022-08-081-9/+11
| | | | | | | | Allows adding additional properties to the target after the initial call to qt_internal_add_plugin. Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Allow specifying multiple header types in qt_copy_framework_headersAlexey Edelev2022-08-052-38/+31
| | | | | | | | | qt_copy_framework_headers now can accept all the headers in one call. This is useful for upcoming changes when it will accept generator expressions as the input instead of actual files. Change-Id: I110b6d9e6de976b2a7581902e051e38571716c5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix examples to build as external projects when cross-compilingAlexandru Croitor2022-08-051-4/+35
| | | | | | | | | | | | | We forwarded the compiler path to the EP but not the flags that might have been set via the CXX environment variable. Make sure to also forward the flags. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix Ninja Multi-Config dependency issues for top-level targetsAlexandru Croitor2022-08-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 12:35:50 +0000