summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-116-116/+203
| | | | | | | | | | | | | | | | | | | | Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.1 Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Split qt_repo_build() into reusable macrosAlexandru Croitor2021-05-101-2/+21
| | | | | | | | | | Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.1 Change-Id: I7ba4507fc7da2dc550317848751502b8b46c298c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't build cmake build tests as macOS universalAlexandru Croitor2021-05-101-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want standalone tests added by qt_internal_add_test to be built as universal executables, so we can build them on an intel machine and run them on an ARM machine. But CMake build tests will be built on the final machine that runs the tests and it might lack a universal SDK. That's why they should be built only targeting the architecture of the machine they're running on. Change the generated qt.tooclhain.cmake file to allow opting in or out of building projects with the same architectures as Qt was configured with. Now standalone tests will be multi-arch, but CMake build tests will be single-arch. Amends e379147f9571af8c3af5768b9040e0180819a855 Task-number: QTBUG-85447 Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix developer buildJoerg Bornemann2021-05-101-0/+2
| | | | | | | | | The -developer-build had not the desired effect anymore. That argument must not be hidden from the feature logic. This amends commit d5c3e1336bc. Change-Id: I96562ea2df43ba7de002e705f28c7cc7edb4a589 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Allow to load -developer-build without configurations into an IDEKai Köhne2021-05-071-0/+12
| | | | | | | | | | | | | | | Let -developer-build, -cmake-file-api set up the CMake File API query, so that the build can be loaded directly into IDE's like Qt Creator. [ChangeLog][Build System] configure -developer-build now sets up the CMake File API query, so that a build can be loaded without reconfiguration into Qt Creator and other IDE's. Pass -developer-build -no-cmake-file-api to configure to disable this. Fixes: QTBUG-89487 Change-Id: I69199b8f96da02e42e5610aa6f49881c1582f7da Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* CMake: fix build with static BrotliLi Xinwei2021-05-071-0/+7
| | | | | | | | | | BrotliCommon is a dependency of BrotliDec and BrotliEnc. amends 5d2da76c1ee70ffd1f027365c0f3af74b76fd382 Pick-to: 6.1 Change-Id: I7741d417e95737f8caacd01962985a27dbb7514c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add instructions for Windows 10 on Arm configSimo Fält2021-05-052-0/+16
| | | | | | | Task-number: QTQAINFRA-3966 Change-Id: Ib8ac80a5b8aa5c88d9e5d0eaad9ba550cc2442f8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Fathi Boudra
* Add -write-options-for-conan configure argumentJoerg Bornemann2021-05-051-2/+78
| | | | | | | | | | | Passing this configure argument will generate a JSON file that contains information about configure options and features. This file is used by Qt's conan recipes. Fixes: QTBUG-92082 Change-Id: I2057ec8cbdb0a1ea198d7eeacb45f65bfa862d8a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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. Pick-to: 6.1 Change-Id: Ibb28ef757228e1a1176ff70c3ec57b7ca751a636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add ABI suffix to .prl files for AndroidJoerg Bornemann2021-05-031-1/+5
| | | | | | | | | The libraries already contain the ABI suffix, and the .prl files should too. This is a requirement for ABI-stitching of Qt Android builds. Fixes: QTBUG-90023 Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Update the comment in QtFinishPrlFile.cmakeJoerg Bornemann2021-05-031-2/+4
| | | | | | | | Clarify that OUT_FILE is not the final .prl anymore and where we get the path of the final .prl from. Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: FreeBSD has DF_ORIGIN supportThiago Macieira2021-05-011-1/+1
| | | | | | Pick-to: 6.1 6.0 Change-Id: I755911ae7d0341f49039fffd167afce7fe6b2b38 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add _qt_internal_wrap_tool_command to replace QT_TOOL_PATH_SETUP_COMMANDAlexey Edelev2021-04-301-0/+15
| | | | | | | | | | | | | | | | | | | QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call add_custom_command/add_custom_target. This is necessary to setup the necessary environment for the tool to run correctly. This approach is weak according to CMake documentation: "If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script." This change introduces the _qt_internal_wrap_tool_command function that uses a wrapping script that setups necessary environment for the tool and runs it in a single shell. The script is generated by the _qt_generate_tool_command_wrapper function. Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not use qt_internal_module_info for non-module targetsAlexey Edelev2021-04-302-4/+10
| | | | | | | | | | | | The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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 Pick-to: 6.1 Fixes: QTBUG-86670 Fixes: QTBUG-91887 Fixes: QTBUG-92578 Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make a documentation-only build possibleJoerg Bornemann2021-04-291-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Packagers usually build Qt per repo, but the documentation must be built from the full Qt source archive to ensure that inter-repo links are set up correctly. When building the documentation, it's desirable to avoid building tools and re-use to tools of an existing Qt build. One now can do a documentation-only build by configuring Qt like this: cmake /path/to/Qt/source -GNinja \ -DQT_HOST_PATH=/path/to/Qt/installation and build the documentation with ninja docs To avoid building tools, this patch removes the DEPENDS arguments from some add_custom_target calls in QtDocsHelpers.cmake and makes another one conditional. The removed dependencies are added at the end of qt_internal_add_docs. Adding of tool dependencies is not done if QT_HOST_PATH is set. Fixes: QTBUG-88441 Change-Id: I3b7a908e22d252d2edcdc1dd522a78b8ad6c487e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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. Pick-to: 6.1 Change-Id: I79286e1c0642068bdfa5d24c1087ee0c39e48f1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: do not set autodetect wasm true until we actually detectLorn Potter2021-04-271-1/+1
| | | | | Change-Id: Ib6bdd3d5ed7dab108b636284ee564d14dbc2d5c8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* 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. Pick-to: 6.1 Fixes: QTBUG-91405 Change-Id: I07efb4afb51ba69d2f5467d272118fa51637ab54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make qt-internal-configure-tests relocatableAlexandru Croitor2021-04-262-14/+21
| | | | | | | | | It's important for conan CI builds where the correct installation location of Qt should be used when configuring standalone tests. Task-number: QTBUG-93037 Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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. Pick-to: 6.1 6.0 Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Error out if requesting Android build without toolchain fileJoerg Bornemann2021-04-231-0/+6
| | | | | | | | | | Passing Android-related variables to the initial CMake call would have no effect if no (or an empty) value of CMAKE_TOOLCHAIN_FILE was specified. To alleviate user confusion, yield an error if an Android build was apparantly requested, but the toolchain file is missing. Change-Id: I28ec94eabe436d4b9b410b48c7cad1b48d3e1bec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Android: Choose latest version when autodetecting the NDKJoerg Bornemann2021-04-231-2/+21
| | | | | | | | | | | | Before, we relied on the deprecated "ndk-bundle" subdirectory being present in the SDK root. Now, we choose the NDK with the latest version in the SDK's ndk subdirectory. Pick-to: 6.1 Fixes: QTBUG-87579 Change-Id: I37a9e03184f4518b4074d55375af08209591de94 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Android: Do not auto-detect NDK if ANDROID_NDK_ROOT is setJoerg Bornemann2021-04-231-1/+1
| | | | | | | | | | | | | When ANDROID_NDK_ROOT is explicitly set by the user, there's no point in detecting the NDK. The detection had no effect, because the already set ANDROID_NDK_ROOT variable would not be overwritten by our set call. Fix the condition of the check: There is no CMAKE_ANDROID_NDK_ROOT variable. Pick-to: 6.1 Change-Id: I8f0d4f2a1a67445f67a79c7d2d0932099828b05e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow enabling Apple app extension API in other reposAlexandru Croitor2021-04-232-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 Pick-to: 6.1 Change-Id: Ia2470e48a91385239394368780f5bbb223000113 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Lowercase system includes and lib names for Windows, fix cross compilingMartin Storsjö2021-04-231-1/+1
| | | | | | | | | | | | | | | When cross compiling from a case sensitive file system, casing matters, and mingw headers and import libraries consistently use lowercase. This was uncovered by d385158d5213ef568b7629e2aa4a818016bbffac; prior to that, the schannel TLS plugin didn't end up built (at least when cross compiling). Fix other similar cases that can be found by grepping the repo. Change-Id: Ia696e17b7aaa979d7b7f5b0801383f338a8b585b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Allow usage of QtStandaloneTestTemplateProject as package componentCristian Adam2021-04-234-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 Pick-to: 6.1 Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add Solaris support in cmake buildNiclas Rosenvik2021-04-214-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add SOLARIS cmake platform definition. Add settings for QT_DEFAULT_MKSPEC so that qplatformdefs.h can be found. Solaris has its gssapi symbols in libgss. Solaris supports @ORIGIN. Solaris ld does not support --dynamic-list needed for reduce relocations. Make solaris fail the reduce relocation test. getauxval is specific to GNU libc and some other libc implementations on Linux but sys/auxv.h is not. The bootstrap uses sys/aux.h as the only indication for getauxval. This breaks builds on Solaris, so only make sys/auxv.h an indicator for getauxval on linux or glibc based systems. Solaris uses X11 so add it to the X11_SUPPORTED list. Solaris network libraries for sockets etc are in socket and nsl. ifreq does not have a member ifr_ifindex on Solaris, it uses ifr_index. Add test to check if ifr_index is a member of ifreq. The first struct in the in_addr union on solaris is defined as four uint8_t, therefore four arguments are needed for its initializer list. Change-Id: Ieed4c1bbac8559a7ae1db9c4e1e91f609f150270 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.1 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>
* 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. Pick-to: 6.1 Change-Id: I9c37b20672f9d0f470e3e9ea847e5221f43bfc04 Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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 Pick-to: 6.1 Change-Id: I2fa8d3293dd55ebc18937e13fac40d144ca4c1e2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-193-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 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@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. Pick-to: 6.1 Change-Id: I8bd8649be4f680a331ad51925f27cb9d13ac5e5f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* 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. Pick-to: 6.1 6.0 Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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 Pick-to: 6.1 6.0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Switch metatypes generation on by default for Qt modulesUlf Hermann2021-04-161-9/+19
| | | | | | | | | | We need the metatypes for anything directly or indirectly exposed to QML. Switching this on has no runtime overhead. For interface libraries we cannot generate any metatypes, though. Change-Id: I7b7f85bb4e16c28d00383c5c88b0f1c172c8d193 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Merge integration refs/builds/qtci/dev/1618489823Qt CI Bot2021-04-152-1/+2
|\
| * CMake: Don't consider /opt/homebrew as a system path for arm64 macOSAlexandru Croitor2021-04-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Homebrew introduced a new default prefix for Apple Silicon machines, so that both arm64 and x86_64 packages can be co-installed on a single system. The intel packages are installed into /usr/local and the arm64 packages are installed into /opt/homebrew. For Qt building purposes, we don't want to find packages in any of homebrew's prefixes unless explicitly requested by the user Currently our arm64 macOS CI config does pick up system libs under new prefix. Remove the new path from the system prefixes. Amends f3c7d22dd04afe8d889585fb5d6426f3d4591e74 Task-number: QTBUG-85447 Change-Id: I381d31c95bcdab26147a331444ba40c7af9d0a95 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
| * CMake: Use PROJECT_VERSION for generated QtModule.json filesAlexandru Croitor2021-04-151-1/+1
| | | | | | | | | | | | | | | | So that the correct version is generated in top-level builds. Change-Id: I360370815ce178564cc79157dc61d70adfd4f947 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* | Check if all required Qt targets are declared when finalizing the moduleAlexey Edelev2021-04-151-0/+3
|/ | | | | | | | | | | | | | | | | | CMake makes possible to specify a target in the target_link_library call even if the target is not declared yet. This adds flexibility to the target declaration arrangement. For the Qt modules we have to restrict freedom, because of the .prl files generating. If the Qt module depends on another Qt module, the dependecy must be declared before the module finalizing step, otherwise this will cause invalid records in the module .prl file. TODO: The dependency order issue could be solved by using conditional genex's when generating step1 .prl file. But we ask developers to depend on Qt module targets that have been defined before their usage. Fixes: QTBUG-89467 Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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. Pick-to: 6.1 Change-Id: I9bd088f317917544ccfeff61fc4ff90f18f0f3d8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Fix default architecture selection for macOS and iOSAlexandru Croitor2021-04-141-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add CoreMotion to the list of looked-up frameworks (Mac/iOS)Juha Vuolle2021-04-141-1/+1
| | | | | | | | The CoreMotion is required by the QtSensor module. Task-number: QTBUG-92502 Change-Id: I7f1853131aa96b2cb052862d5bf492df5ec18150 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge integration refs/builds/qtci/dev/1618224780Qt CI Bot2021-04-121-2/+2
|\
| * Use bracket-based escaping for all list arguments in a configure stringAlexey Edelev2021-04-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The 'list(TRANSFORM cmake_args REPLACE "\\[\\[;\\]\\]" "\\\\;")' call breaks the list arguments added when evaluating the 'INPUT_' values. Therefore, it's necessary to apply bracket-based escaping to all list arguments instead of the standard escaping. Amends 856fadf85ca2a3b70878d01d32e4d4cef807b8a9 Fixes: QTBUG-92459 Change-Id: Ifd4e0ca5f549a1c7fab9ceb587ed355250c4e677 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | CMake: Fix condition evaluation in plugin's DEFAULT_IF optionAlexandru Croitor2021-04-121-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Pick-to: 6.1 Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 15:02:52 +0000