summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* Replace flags with spaces when removing themAlexey Edelev2021-06-121-2/+2
| | | | | | | | | | | | Removing flags based on REGEX may include spaces, so flags might be glued. Replace flags with spaces to keep at least one space for the described case. Fixes: QTBUG-94400 Change-Id: Ice268da36174ef5cf4398d2aee8fcd4731336316 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 523ee5577a3fb1801dc765511c2c76753c10a72e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix generated prl and pri files for MSVCLi Xinwei2021-06-025-5/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 2c49f85380d7ad79d9473e0f42e7afaa36d31af9) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Pass OpenGL_GL_PREFERENCE variable to other Qt reposJoerg Bornemann2021-06-011-0/+8
| | | | | | | | | | | | | | | When building Linux packages, we pass OpenGL_GL_PREFERENCE=LEGACY when building qtbase. This is done to link against legacy OpenGL libs. When building non-qtbase repos, we also need to set this variable to the same value we have in qtbase. Task-number: QTBUG-89754 Fixes: QTBUG-94040 Change-Id: I567b629d245025d2b1544b91cfc265a9c921725f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 20feedac95c519c71d4db93ab28ad1a110dfbcca) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add QT_CONFIGURE_RUNNING variable for configure.cmake filesJoerg Bornemann2021-06-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | configure.cmake files are read twice when using the configure script / qt-configure-module: First, when configure is running and a second time, when CMake creates the local build system files. In the first run, not every function and esp. no targets are available. Code in configure.cmake that accesses targets or calls functions unknown to configure will fail at the configure stage. This patch introduces the QT_CONFIGURE_RUNNING variable that can be used in configure.cmake files to guard such code: if(QT_CONFIGURE_RUNNING) set(_qt_coord_type double) else() get_property(_qt_coord_type TARGET Qt6::Core PROPERTY INTERFACE_QT_COORD_TYPE) endif() Change-Id: Iff39924d6a5133379d28c8204d7b7afdf47de5c8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 37452051d6b68f20a52c65cffd3cde5cb323156e) Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: fix CMake function qt_commandline_addStringHaoyu Liu2021-05-251-1/+1
| | | | | | | | | | 1. a missing '}' breaks CMake 2. the variable "opt" should really be "arg", otherwise it'll be meaningless Change-Id: If29557998bf7aa786dc5c821e2c55f1195e7922b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit c3804ba061ef7ea073dab2855502d35a4d3a67df) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Enable UNICODE for all Qt targets and Qt consumers by defaultAlexey Edelev2021-05-213-8/+16
| | | | | | | | | | | | | | | | | | | After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 715041b663ababa8b36f90978d20bdcdd80e3117) Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Do not expose Qt internals by the HEADER_MODULEsAlexey Edelev2021-05-201-1/+2
| | | | | | | | | | | | | | | | | | | HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Don't do plugin initialization for static librariesAlexandru Croitor2021-05-201-0/+7
| | | | | | | | | | | | | | | | | | | | Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 5268edf5811251a432fb5096aef6de4ef372f619)
* CMake: add an option to enable or disable versioned hard linkLi Xinwei2021-05-122-0/+8
| | | | | | | | | | | | The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it is set to ON. Users can set this option to OFF to disable versioned hard link. Fixes: QTBUG-93636 Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 320c282488f4ae4cae735b0be027170803d06cd7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix typo in FindWrapAtomic.cmakeJohn Zimmermann2021-05-121-3/+3
| | | | | | | | | There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 224fccdaecbabf72caef3cc7996afe7ad3a857f5) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* cmake: FreeBSD has DF_ORIGIN supportThiago Macieira2021-05-121-1/+1
| | | | | | | Change-Id: I755911ae7d0341f49039fffd167afce7fe6b2b38 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit d08d456844ba58c977bf83fc8e48085cbc75abfc) (also cherry-picks fadd87ed15b5f7bf6e7aaed1263e2f2d661a623d)
* CMake: use additional search paths also for tool packageSamuli Piippo2021-05-101-1/+5
| | | | | | | | | | | Use paths configured with QT_ADDITIONAL_PACKAGES_PREFIX_PATH to search also for the tool packages. Task-number: QTBUG-93565 Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 60c87c68016c6f02b0eddd4002f75a49ab51d4a8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Don't use list(PREPEND) in qt.toolchain.cmakeAlexandru Croitor2021-05-101-2/+3
| | | | | | | | | | | | | | | | | | list(PREPEND) command was added in CMake 3.15+, but so far we claim support for CMake 3.14 in user projects. Use set command instead. This is not the only place where we use list PREPEND in public API, but it's the first immediate issue that comes up when using CMake 3.14. Amends 963017f58884dfd929249c5546aadbb0f74501e8 Change-Id: I7ba4507fc7da2dc550317848751502b8b46c298c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit c457e65bf40a8cccff283609924078b5ff985709) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix installation of Find*.cmake files in shadow per-repo buildsJoerg Bornemann2021-05-071-1/+1
| | | | | | | | | | | | | In shadow per-repo builds we never hit the code that is supposed to install cmake/Find*.cmake files. This caused problems when statically building a Qt repo like qtshadertools against qtimageformats which provides such Find*.cmake files. Fixes: QTBUG-91538 Change-Id: I1147daee817ac71303d93e8bf368b2769afb0bb4 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 232c70ecc85243205d4cdd62b6d31dcc32dafeba)
* CMake: fix build with static BrotliLi Xinwei2021-05-071-0/+7
| | | | | | | | | | | BrotliCommon is a dependency of BrotliDec and BrotliEnc. amends 5d2da76c1ee70ffd1f027365c0f3af74b76fd382 Change-Id: I7741d417e95737f8caacd01962985a27dbb7514c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit d104d510ea6c4f3a24f5d6105930d57c6aee0cb6) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix Windows build with CMake < 3.19Joerg Bornemann2021-05-051-2/+2
| | | | | | | | | | | | | | | file(REAL_PATH) was introduced in CMake 3.19. Use get_file_name_component(... REALPATH) instead that is available in older CMake versions. This amends commit b226e99c71c. Change-Id: Ibb28ef757228e1a1176ff70c3ec57b7ca751a636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> (cherry picked from commit 33ac3cf7664aa08e3455e516c0d44d923b29955d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Allow usage of QtStandaloneTestTemplateProject as package componentCristian Adam2021-05-034-30/+46
| | | | | | | | | | | | | | | | | | | | | | | | Currently in order to compile a Qt6 test standalone one needs to use the qt-cmake-standalone-test script which will load the Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project with the current test source directory to create a complete CMake project. This commit will allow a test to have these lines at top: cmake_minimum_required(VERSION 3.16) if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT) project(a_qt_test LANGUAGES C CXX ASM) find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST) endif() and be standalone and work with any IDE capable of loading CMake projects. Fixes: QTCREATORBUG-25389 Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 0a1256a52d8c6c1b85a10f7dc94dfc34e3540040) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix reconfiguration when using a static top-level buildAlexandru Croitor2021-04-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | ... and configuring another repo using qt-configure-module. It's possible to configure a top-level Qt with a subset of repos and then afterwards configure additional repos with qt-configure-module. We didn't define QT_REPO_DEPENDENCIES in that case, which caused all plugin config files to be loaded on reconfiguration, thus causing duplicate target errors. Move the QT_SUPERBUILD check to be done every time in QtBuildInternals.cmake rather than when configuring qtbase/qt5. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Fixes: QTBUG-86670 Fixes: QTBUG-91887 Fixes: QTBUG-92578 Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit e1c1558218168529ea3fd1ab2e8b775c152ef7ee) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Add versioned alias for the Platform targetAlexey Edelev2021-04-271-0/+1
| | | | | | | | | | It's necessary to have versioned alias of the Platform target to use versioned target in the installable cmake files. Change-Id: I79286e1c0642068bdfa5d24c1087ee0c39e48f1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 8f238788de8fddd08c63a3437029ddfe19a9ee52) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix plugin SKIP_INSTALL optionAlexey Edelev2021-04-271-5/+14
| | | | | | | | | | | If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 361daa2990ddb70805d356ce5df7d8cfae8e1954)
* Skip adding externally added plugins to the plugin meta-setsAlexey Edelev2021-04-271-3/+7
| | | | | | | | | Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit bbe26a766748c00da5e2241a9c7ec5e714dd76ad)
* Fix linking order of the resource objectsAlexey Edelev2021-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 4ed9402d7a752c739a371706fd5cd82e4626539e)
* Inhibit CMake generator detection for qt-configure-moduleJoerg Bornemann2021-04-261-1/+2
| | | | | | | | | | | | | | | When configuring a Qt module with qt-configure-module, we want to use the same CMake generator that was used for building qtbase. That generator is encoded in qt-cmake-private. But qt-configure-module overrides the generator after trying to detect what generator should be used. That auto-detection is only useful for qtbase-builds and top-level builds. Turn it off for repo builds other than qtbase. Fixes: QTBUG-91405 Change-Id: I07efb4afb51ba69d2f5467d272118fa51637ab54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 52077d4f0193a236eacac98f75994b44a4c30a91) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Install prl files from all repo build dirs in a top-level buildAlexandru Croitor2021-04-261-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, in a top-level build we always generated the final prl file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After each repo was processed by QtPostProcess.cmake, we installed the prl files found in PROJECT_BINARY_DIR. For qtquickcontrols2 this meant that qml plugin prl files were placed under qtbase/qml, but we tried installing the prl files from qtquickcontrols2/qml, which didn't have any prl files. In a static Qt build, qmake's qt.prf calls qmlimportscanner to identify which plugins should be linked to the executable. This worked fine because the plugin .pri files were installed correctly. None of the qml plugin library dependencies were linked in though. This is supposed to happen in qmake's C++ code where it tries to find the associated prl file of a linked library in order to extract all its dependencies. Because no prl file was found, linking failed with multiple undefined symbols. Fix this by installing the prl files from QT_BUILD_DIR rather than PROJECT_BINARY_DIR. Note that this will create multiple install rules for certain files, but it's harmless. An example is imageformats. We process qtbase plugins, see qjpeg, issue an install rule from under the qtbase/plugins/imageformats folder. We then process qtimageformats plugins, see webp, issue another install rule from under qtbase/plugins/imageformats. The first install rule will install both qjpeg and qwebp, the second install rule will merely say all plugins are up-to-date. Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 31ee3c84a78afa67eeb4e4b6da5a8181ea62c387) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Allow enabling Apple app extension API in other reposAlexandru Croitor2021-04-262-3/+4
| | | | | | | | | | | | | | It's needed in qtconnectivity, but currently the qt_disable_apple_app_extension_api_only function is defined in QtInternalTargets.cmake which is loaded only in qtbase. Move the function to cmake/QtTargetHelpers.cmake. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Change-Id: Ia2470e48a91385239394368780f5bbb223000113 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 393f45de907d8c6bca9bdb33d08a6309034c89f5)
* CMake: Fix auto-linking of static plugins for non-QML in-tree testsAlexandru Croitor2021-04-222-16/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 6969496e0078f9f9df9bef817caad71cf5213e3a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix auto-linking of static plugins in standalone testsAlexandru Croitor2021-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change introduced in 98e8180e56322ce065e39cc1ef1d65b54caa8c25 fixes reconfiguration issues for repositories that provide plugins associated with modules from a different repository (QSvgPlugin -> QtGui -> qtbase). It does so by only loading the public Plugin CMake packages of dependent repositories. For executables / tests that are built as part of the current repository, plugins are linked via a different simplified mechanism in qt_add_internal_plugin and qt_internal_add_plugin in order to prevent exporting link cycles between plugins and Qt modules. This works for the majority of in-tree tests, but unfortunately breaks static standalone tests. For example in qtbase neither mechanism will link plugins to the standalone tests: - qtbase has no repo dependencies, so the first mechanism (loading of public plugin packages) is skipped because we assume we are merely reconfiguring the main build of qtbase and we don't want to accidentally create duplicate plugin targets - because a standalone test configuration does not call qt_internal_add_plugin, no association is done between qt plugin and module and thus all tests (qt_internal_add_test -> qt_internal_add_executable) don't get the simplified plugin linking Fix this by allowing loading of the public CMake plugin packages when doing standalone tests. It should be safe to do so because we don't build any plugins in this case, only tests. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Task-number: QTBUG-87580 Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit be1ee03a0fafa28efa0c0e45f21f9dc684625957) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* MSVC: define _CRT_SECURE_NO_WARNINGS for all internal CMake targetsLi Xinwei2021-04-202-4/+1
| | | | | | | | | | | | | | | | | | In commit 013abe320680b3dcd3f6d7e4fb4880e590ba10e6, I add _CRT_SECURE_NO_WARNINGS definition for all Qt internal module targets, to suppress MSVC warnings like: warning C4996: 'strncpy': This function or variable may be unsafe. However, when compiling some internal tools, such as qmake and qdoc, such warnings also exist. To suppress this kind of warning entirely, _CRT_SECURE_NO_WARNINGS definition should be added for all Qt internal targets when using MSVC compiler. Change-Id: I9c37b20672f9d0f470e3e9ea847e5221f43bfc04 Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit c7a27678d6916a51848c991fb3ee21acc6a6f8ca) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* make FindWrapBrotli.cmake not depend on vcpkg or PkgConfigLi Xinwei2021-04-201-0/+47
| | | | | | | | | | | | | | | | | Currently, FindWrapBrotli.cmake depends on vcpkg or PkgConfig. But for users who build Brotli by themselves and don't have vcpkg or PkgConfig, the Brotli cannot be found. As a reference, I use following CMake commands to build Brotli: cmake path/to/Brotli/source -G"Ninja Multi-Config" -DCMAKE_CONFIGURATION_TYPES=Release;Debug -DCMAKE_CROSS_CONFIGS=all -DCMAKE_DEFAULT_CONFIGS=all -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=path/to/install Change-Id: I2fa8d3293dd55ebc18937e13fac40d144ca4c1e2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 5d2da76c1ee70ffd1f027365c0f3af74b76fd382) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-203-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io> (cherry picked from commit 4d838dae5a821e9e5f013ba1d5a494ece1b5180e) Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Introduce zlib find script to work around hardcoded iOS SDKAlexandru Croitor2021-04-191-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xcode allows building a project targeting either the device or simulator sysroot in one single build dir, but for the sysroot switching to work there should be no linker or compiler flags referencing absolute paths of a specific sysroot. During CMake configuration of a project targeting iOS, all found system libraries will be within one single sysroot, either the device one or the simulator one, whichever one was passed to CMAKE_OSX_SYSROOT. CMake will then generate the Xcode project and pass those absolute paths, which makes sysroot switching within Xcode not work. To avoid that, the CMake documentation recommends passing linker and framework flags of the form '-lfoo' and '-framework bar' instead of absolute paths. Xcode then takes care of setting the correct framework search path. Zlib is one of the libraries found in the iOS sysroot and thus passed as absolute path. To avoid that, create a new FindWrapZLIB find script. The target it creates will pass the absolute path to the library on non Apple platforms and an -lz linker flag on Apple platforms (macOS and iOS). To avoid issues with target global promotion when system PNG package is found, ensure that a found ZLIB::ZLIB target is promoted to global manually in src/gui/configure.cmake. Change-Id: I8bd8649be4f680a331ad51925f27cb9d13ac5e5f Reviewed-by: Cristian Adam <cristian.adam@qt.io> (cherry picked from commit b25eb6e0bd1e3b91c44dc4892d529b95c8677889) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix DESTDIR handling on Windows for Qt modules != qtbaseJoerg Bornemann2021-04-191-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | On the CI system, we build qtbase with CMAKE_INSTALL_PREFIX set to a path without a drive letter to support DESTDIR when installing. Other Qt modules are built without CMAKE_INSTALL_PREFIX set. The Qt6BuildInternals package provides a default value. Since commit e6527e2f73663205a0f36feac5a7feda47fba152 this default prefix is calculated from the current installation location. This default prefix however has a drive letter, breaking DESTDIR support. Broken DESTDIR support in this case means for Android that file(INSTALL) can properly install but stripping will silently fail. We now compare the "real path" of the original prefix from qtbase and the calculated prefix. When they're equal, we use the original CMAKE_INSTALL_PREFIX. Fixes: QTBUG-92890 Change-Id: I96fb0655e02c5c695722b7e01a32e209cbdea4cc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 15b26935fca4ab14298abdcc70b3cb15b6cca195) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix top-level build repository targetsJoerg Bornemann2021-04-191-9/+10
| | | | | | | | | | | | | The directory-level targets missed the first level of sub-targets. E.g. `qtbase_qmake` did not have a dependency to `qmake`. Fix qt_build_internals_get_repo_targets to first grab all targets of the subdirectory and then recurse. Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 82f8519b827ba7fd89f8168632461f47b09605a7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Warn when using CMake 3.20.1 due to crashes in AUTOMOCAlexandru Croitor2021-04-171-0/+6
| | | | | | | | | | | | | With CMake 3.20.1 AUTOMOC can crash or hang on Windows when used with a Qt installation that supports moc depfiles due to missing multi-threaded locking. Warn and advise to use a different CMake version instead. Change-Id: I78d2269c48dfc2541bebcd6ab23aaa5595012149 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit aab8a0ac6e5365d97d3c7571b26430776b7b5f49) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix default architecture selection for macOS and iOSAlexandru Croitor2021-04-162-9/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit e379147f9571af8c3af5768b9040e0180819a855)
* CMake: Fix hardcoded iOS SDK when finding OpenGLESAlexandru Croitor2021-04-151-2/+2
| | | | | | | | | | | | | | | | | The find script checked for UIKIT which is set during a Qt build in QtPlaformSupport.cmake but is not set when building a user project. This casused the find script to skip the iOS specific code that passed the -framework OpenGLES linker flag. This broke SDK switching in Xcode. Check the IOS variable instead which is set by CMake for all projects that pass -DCMAKE_SYSTEM_NAME=iOS. Change-Id: I9bd088f317917544ccfeff61fc4ff90f18f0f3d8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit ed5543475e614cc1b1eb3fbee6a635805bb6c805) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix error when re-configuring an already installed Qt repositoryJoerg Bornemann2021-04-134-4/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 98e8180e56322ce065e39cc1ef1d65b54caa8c25)
* CMake: Fix condition evaluation in plugin's DEFAULT_IF optionAlexandru Croitor2021-04-131-6/+6
| | | | | | | | | | | | | Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit c1ac201f5c9905751eb35531f26311c8d291f9cc) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix auto-importing of plugins in static Qt qmake projectsAlexandru Croitor2021-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the plugin .pri files that CMake generated for qmake consumption contained an '-' to exclude the plugin from auto-importing only if the plugin type was generic or a platform plugin. Now that plugin projects that should be excluded have a proper DEFAULT_IF FALSE clause, we can simply query for the defaultness of the plugin to know whether to exclude it in the generated .pri file. This fixes an issue with Qt static builds and qtvirtualkeyboard. The vkb plugin was not excluded and thus any simple QtGui app linked to the vkb plugin in a static qmake project. This led to linker issues because the vkb plugin also depends on a vkb quick plugin which is not listed as a dependency. Augments 76230d98795a2e7a365328eb693ff57f6ddd7f1d Amends c975c35eaebcca3bd33931fecc3beb513e332292 Fixes: QTBUG-92529 Task-number: QTBUG-87861 Change-Id: I9671f6504374cf0799289bbe19110e01c129402e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit b6dd5d7c3b6735ef0f50c7eb068727496bff4abf) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix duplicate symbol errors in Windows static super buildsAlexandru Croitor2021-04-131-18/+21
| | | | | | | | | | | | | | | | | | | | | | | | | qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit ededf3914297aca62e1d257175305cab5dbf6da2)
* Warn if using CMake 3.20.0 due to potential cyclic dependenciesCraig Scott2021-04-121-0/+5
| | | | | | | | | | | CMake 3.20.0 can create autogen-related cyclic dependencies that are only detected at build time by Ninja, which then fails with a build error. Warn and advise to use a different CMake version instead. Change-Id: I9bef973ad2efdb69f28d6a9e0584b543be59f17f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 6442116078500b0e7c401430b74bd40f32cfafb4) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Avoid using prohibited target property names with INTERFACE targetsCraig Scott2021-04-072-5/+5
| | | | | | | | | | | | | | | | | | | | | CMake 3.19 removed the restrictions on allowable names for properties on INTERFACE targets. With earlier CMake versions (back to CMake 3.11), names for custom properties must begin with either a lowercase letter or an underscore. In 5807e1ae81 (Add plugins to Qt tools and executables for static builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and QT_REPO_PLUGINS were used, but in some cases, the targets on which they were being set are INTERFACE targets. Replace these with names that are supported with CMake 3.11 or later. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Task-number: QTBUG-91915 Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 256dea0df74dc05ded438b33b6be8735048fd402) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Build minimal subset of tests in desktop static buildsAlexandru Croitor2021-04-073-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | Add new configure option -make minimal-static-tests and CMake option QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS it will enable building a minimal subset of tests when targeting a static desktop Qt build. In qtbase the minimal subset includes all the auto tests of testlib, tools, corelib and cmake. In particular this will also do cmake build tests and qmake build tests (tst_qmake) Adjust CI instructions to enable building a minimal subset of static tests when a platform configuration is tagged with the MinimalStaticTests feature. Fix and skip a few tests that were failing. Task-number: QTBUG-87580 Task-number: QTBUG-91869 Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 0e6c4224f00999d4089d7c2ac462bb5a60a14adc) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix DESTDIR support on Windows for versioned hard-linksJoerg Bornemann2021-03-311-4/+16
| | | | | | | | | | | On Windows, we need to strip drive letter and colon before prepending DESTDIR when creating our versioned hard links. This fixes CI submodule updates. Pick-to: dev Change-Id: I41bc5f27b714ef74d3fadc4a0fb16c3d8b20da1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Semi-handle non-current repo qt modules when creating pluginsAlexandru Croitor2021-03-311-12/+32
| | | | | | | | | | | | | | | | | | | | | | | In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Pick-to: dev Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move bin/qt-internal-configure-tests to libexecJoerg Bornemann2021-03-301-4/+4
| | | | | | | | | Task-number: QTBUG-88791 Change-Id: I78613128760b5820e6db17b0c09462e34f7c7bb2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 4ae9922166ba81c9efea5b2af29898eb20a1fd63) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Improve support for QT_ADDITIONAL_PACKAGES_PREFIX_PATHKai Köhne2021-03-303-4/+12
| | | | | | | | | | | | | | | | | | | | Allow to set QT_ADDITIONAL_PACKAGES_PREFIX_PATH as both an env variable and CMake cache variable. Also normalize path and list separators, so that they can be used similar to CMAKE_PREFIX_PATH. The environment variable is intended to be set by the conan virtualenv generator, so that e.g. find_package(Qt6 COMPONENTS NetworkAuth REQUIRED) also works if NetworkAuth is not installed into the Qt prefix. Fixes: QTBUG-91142 Change-Id: Ia9f9b9fa2b1b051d33073629139640d0f4c7a843 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> (cherry picked from commit 5bbd700124d13a292ff8bae6045316112500e230) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix CMAKE_INSTALL_PREFIX when building against installer-provided QtJoerg Bornemann2021-03-301-1/+1
| | | | | | | | | | | | | | | | | When building a module against an installer-provided Qt, CMAKE_INSTALL_PREFIX would default to /home/qt/work/install, which is the install prefix of our packaging machines. Do not hard-code the install prefix in QtBuildInternalsExtra.cmake but use the one that is calculated from the location of QtBuildInternalsExtra.cmake. Fixes: QTBUG-90449 Fixes: QTBUG-91475 Change-Id: I39f214efb18796a89f00a171ef190c547bba5c0a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit e6527e2f73663205a0f36feac5a7feda47fba152) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix build of QTuioTouchPlugin with Makefile generator on macOSJoerg Bornemann2021-03-301-2/+8
| | | | | | | | | | | | | | | | | | For each plugin, we create a custom target with it's OUTPUT_NAME such that one simply can do 'ninja qtuiotouchplugin' to build it. QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is problematic with Makefile generators on case-insensitive file systems. See CMake upstream issue #21915 for details. Work around this issue by not creating the custom target in this situation. Fixes: QTBUG-84342 Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 82d50925f1a7d4ff852e5302fd9e8a3ae18763d0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* headersclean: Compile with -std=c++latest, -Zc:__cplusplus on MSVCKai Köhne2021-03-301-1/+1
| | | | | | | | | | | | c++latest does check that our headers also work with upcoming C++20 support in MSVC. It also implicitly sets -permissive-, which checks for stricter standards compliance. Task-number: QTBUG-91117 Change-Id: Iaf1547191969213d570a1b2f59888ad04a7977ab Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit b58ca067da7dad3e151231c58f60238ed01cb65b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 02:21:10 +0000