summaryrefslogtreecommitdiffstats
path: root/cmake/QtSetup.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Display CMAKE_BUILD_TYPE when including QtSetupAlexandru Croitor2022-01-211-0/+2
| | | | | | | | | | This will show the CMAKE_BUILD_TYPE that was computed for a configured repo or standalone tests, after the logic in QtBuildInternalsExtra.cmake is executed. Pick-to: 6.2 6.3 Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Rework how installation is prevented in non-prefix buildsJoerg Bornemann2021-09-221-3/+0
| | | | | | | | | | | | | | | | | In non-prefix builds, we want to prevent users from accidentally running "cmake --install". We did that by replacing cmake_install.cmake with an empty file. The responsible target remove_cmake_install is visible in IDEs, appears in the build output, and the approach is hacky. It's cleaner and easier to add bail out code at the top of cmake_install.cmake. This is now done when calling qt_build_repo_begin. As a bonus, print an informative message on installation. Change-Id: I022b36289358ba09cac8b79781f44cd7b93113f7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow opting out of building examples as ExternalProjectsAlexandru Croitor2021-09-061-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We default to configuring examples as separate ExternalProjects when using a developer / non-prefix Qt build. This ensures we test that the examples configure successfully without the pollution of the main Qt build (e.g. already found packages). One down-side of this is that a developer's IDE doesn't see these example targets, unless each project is loaded into the IDE separately. This is cumbersome to do when refactoring or renaming code across multiple example projects. Allow configuring the example projects as part of the main Qt build by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt. Save the value of the variable in QtBuildInternalsExtra.cmake.in so it's propagated to leaf repositories as well. Amends dab8f64b6d5d4241b678d0227355858071376496 Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Task-number: QTBUG-90820 Task-number: QTBUG-94608 Task-number: QTBUG-96232 Task-number: QTCREATORBUG-26168 Pick-to: 6.2 Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Error out if ccache is requested but not foundJoerg Bornemann2021-08-271-1/+1
| | | | | | | | | | | | | Before, we would just issue a warning which is likely to get overlooked in CMake's output. Also, the configure summary would report "Using ccache ... yes" but CMAKE_<LANG>_COMPILER_LAUNCHER stays unset, which is inconsistent. Make QT_USE_CCACHE=ON and missing ccache a hard error. Task-number: QTBUG-88308 Change-Id: Iddc7f3a91428fd96ad0defbb1ca72bd46a90aa98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Restore default installation prefix from Qt 5Joerg Bornemann2021-07-061-6/+17
| | | | | | | | | | | | | | | | | Change the default installation prefix to C:/Qt/Qt-${version} on Windows and /usr/local/Qt-${version} elsewhere. This is what's expected by users coming from Qt5, and setting the installation prefix to "/usr/local" manually is easier than setting the versioned variant "/usr/local/Qt-6.2.0". [ChangeLog][Build System] The installation prefix now defaults to /usr/local/Qt-${version} and C:/Qt/Qt-${version} like it did in Qt 5. Fixes: QTBUG-91632 Pick-to: 6.2 Change-Id: I8ce57b1b18084c705b194c776e038cc807a6ed5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Propagate sanitizer flags to public projectsAlexandru Croitor2021-06-251-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that Qt user projects build with sanitizer flags if Qt was configured with any of the sanitizers enabled. To compile Qt with sanitizer support enable any of Qt sanitizer features. Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported anymore. When configuring Qt using CMake directly, pass -DFEATURE_sanitizer_address=ON -DFEATURE_sanitizer_undefined=ON instead of -DECM_ENABLE_SANITIZERS=address;undefined When configuring Qt with the configure script pass -sanitize address -sanitize undefined as usual. QtConfig.cmake now records the sanitizer options that should be enabled for all consuming projects based on the enabled Qt features. This applies to internal Qt builds as well as well as tests an examples. The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS variable in the directory scope where find_package(Qt6) is called. The ECMEnableSanitizers module is included to add the necessary flags to all targets in that directory scope or its children. This behavior can be opted out by setting the QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might be handling sanitizer options differently. Amends 7e03bc39b8bcdaa4e83e72ac99e117561c124951 Pick-to: 6.2 Fixes: QTBUG-87989 Task-number: QTBUG-92083 Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6 Reviewed-by: Robert Löhning <robert.loehning@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Build minimal subset of tests in desktop static buildsAlexandru Croitor2021-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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. Pick-to: 6.1 Task-number: QTBUG-87580 Task-number: QTBUG-91869 Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Allow benchmarks with --force-debug-infoAllan Sandfeld Jensen2021-02-051-1/+1
| | | | | | | | Developer builds with RelWithDebInfo should also make benchmarks, it is how we get good traces. Change-Id: I009d40580d5d784f78bd18ebf21887ce3c1fa97d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix invalid Qt prefix version when looking for HostInfo moduleAlexey Edelev2021-01-261-1/+1
| | | | | | | | | | | | | | | | | | | In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to identify prefix of 'Qt<version>HostInfoConfig.cmake'. Qt<version>HostInfo is not found, if project version differs from qtbase version. Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE' variables to 'QtBuildInternalsConfig.cmake'. In this case variables will be exposed for a wider list of internal routines. Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find Qt<version>HostInfo module. Fixes: QTBUG-90345 Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use Release build type by defaultAlexey Edelev2020-12-211-7/+7
| | | | | | | | | | | Use developer-build feature to set Debug build by default instead of .git folder detection Task-number: QTBUG-89410 Fixes: QTBUG-89476 Pick-to: 6.0 Change-Id: I2a4f529299d4875e7b0eef5b41dd7a6b9402178b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use host variables instead of hardcoded directoriesAlexey Edelev2020-12-211-2/+3
| | | | | | | | | | | | | | | | | | | 'QT_HOST_PATH' indicates that we use crosscompilation toolchain to build project. In this case 'Qt6Config.cmake' loads 'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines correct paths to host tools. Replace hardcoded paths for host tools by paths recorded in Qt6HostInfoConfig.cmake. Correct conditions for QT_HOST_PATH, evaluate it explicitly as string, but not as boolean expression. Fixes: QTBUG-86557 Pick-to: 6.0 Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add detection of FEATURE_foo change by userAlexey Edelev2020-12-171-0/+24
| | | | | | | | | | | | | | | | | | | | | Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Offer to build manual tests through QT_BUILD_MANUAL_TESTSAleix Pol2020-12-081-0/+2
| | | | | | | | | Disabled by default as they are currently not being built and many are not working properly, this will allow us to start using them again. Change-Id: I823368d04e9fde2beccabedc3ca15efd1f355bfb Pick-to: 6.0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add extra targets to run single benchmark using CMake generatorAlexey Edelev2020-12-071-3/+6
| | | | | | | | | | | | | | | | | | Add custom targets with '_benchmark' suffixes to make run of benchmarks using generators possible, e.g.: $ ninja tst_bench_qudpsocket_benchmark Extend '-[no]make' option to pass benchmark. Rework '-[no]make' processing to unify these options processing. Also looks like it doesn't make sense to enable benchmarks without having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own dependency automatically. Task-number: QTBUG-89076 Pick-to: 6.0 Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Name QT_NO_MAKE_*/BUILD_* variables consistentlyJoerg Bornemann2020-11-201-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Avoid usage of FEATURE_debug_and_release in QtSetup.cmakeJoerg Bornemann2020-11-091-1/+1
| | | | | | | | | | | If the user turns on debug_and_release with the configure script, FEATURE_debug_and_release will not be set, and the debug postfix won't be set correctly. Directly use FEATURE_debug_and_release's condition instead. Change-Id: Ica4af3caa25f2e6712eca4659818aac2c8b95256 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix configure -developer-buildJoerg Bornemann2020-11-091-0/+6
| | | | | | | | | | | | | | | Configure now translates -developer-build to INPUT_developer_build without setting FEATURE_developer_build. The install prefix determination code in QtSetup.cmake happens much earlier than the feature evaluation. As the developer_build feature is merely a switch that's supposed to be flipped by the user, we can just translate the INPUT_developer_build value to FEATURE_developer_build in QtSetup.cmake. Fixes: QTBUG-88318 Change-Id: I57918232359e2e367e41b779d3f4737731dd76e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Implement configure -reduce-exportsJoerg Bornemann2020-10-051-7/+0
| | | | | | | | | | | | | | | | | This option maps to FEATURE_reduce_exports. The feature is on by default, except for MSVC. The reduce_exports configure test is not used in the CMake build. The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties are now explicitly initialized in the qt_set_common_target_properties function, because we don't have access to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET variables were set before. Task-number: QTBUG-85373 Change-Id: I378453f0e0665731970016170302871e20ceb4e2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: use HostInfo when QT_HOST_PATH is setSamuli Piippo2020-09-301-0/+3
| | | | | | | | | HostInfo is used in places whenever QT_HOST_PATH is set, regardless whether CMAKE_CROSSCOMPILING is set or not. Make sure that HostInfo is available when QT_HOST_PATH is set. Change-Id: I39763a61d77e97dc9c4cc3875bce4deb942f870a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix usage of ccache when no executable was foundAlexandru Croitor2020-08-181-3/+8
| | | | | Change-Id: Ia9a44234cb074fa5ba2b1dc9ca22a676d1b2d4ce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATHAlexandru Croitor2020-07-241-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to implement the 'host artifact reuse' Coin instructions change, a bug surfaced where the qemu configurations didn't find the host tools and instead tried to use the cross-compiled tools while building qtbase, which failed due to not finding the runtime linker (another unsolved issue). Before the host artifact reuse change, the host tools were found successfully. The difference that caused the issue is that the target install prefix was a direct subfolder of the host prefix. host - /home/qt/work/qt/install target - /home/qt/work/qt/install/target Before the host reuse change the install prefixes were as follows host - /home/qt/work/qt/install/host target - /home/qt/work/qt/install/target While looking for the Qt6CoreTools package, we temporarily set CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first '/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'. CMake then reroots the CMAKE_PREFIX_PATH values onto values in CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search. Rerooting essentially means concatenating 2 paths, unless the considered prefix is a subfolder of the root path. What happened was that the first considered value was '/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent location that gets discarded. The second considered value was '/home/qt/work/qt/install/target. The second value is the result of seeing that '/home/qt/work/qt/install/target' is a subfolder of '/home/qt/work/qt/install' and thus the root path is stripped. All of this is done in cmFindPackageCommand::FindConfig() -> cmFindCommon::RerootPaths. The behavior above caused the target tools be found instead of the host ones. Before the host reuse change, both of the initial constructed prefixes were discared due to them not existing, e.g. '/home/qt/work/qt/install/target/home/qt/work/qt/install/target' and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host' One of the later prefixes combined CMAKE_FIND_ROOT_PATH == '/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting in '/home/qt/work/qt/install/host/' and this accidentally found the host tools package. We actually stumbled upon this issue a while ago when implementing Qt 5.14 Android CMake support in 52c799ed4425076df4353c02950ea1444fe5f102 That commit message mentions the fix is to add a "lib/cmake" suffix to the PATHS option of find_package(). This would cause the subfolder => strip root behavior mentioned above. So finally the fix. First, make sure not to append QT_HOST_PATH in the toolchain file, there shouldn't be any need to do that, give that we temporarily set it when looking for Tools packages. Second, recreate the subdir scenario in the Qt toolchain file by setting CMAKE_FIND_ROOT_PATH to the current (relocated) install prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value poining to the CMake directory. Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'. Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host equivalents of the target ones above. Use these values when looking for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing the subdir behavior. Note these are currently absolute paths and are not relocatable. We'll have to figure out if it's even possible to make the host path relocatable. Finally as a cleanup, look for the Qt6HostInfo package in QtSetup strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find a system Qt package. Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix QT_STAGING_PREFIX for repos other than qtbaseJoerg Bornemann2020-07-131-2/+0
| | | | | | | | | | | | | For repositories other than qtbase the QT_STAGING_PREFIX was empty, because it was only determined in qtbase. Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package and set this variable if it's not explicitly set by the user. As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON. Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Introduce QT_STAGING_PREFIXJoerg Bornemann2020-07-091-0/+2
| | | | | | | | | | | Add the cache variable QT_STAGING_PREFIX that is the same as CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise. Use the variable in the places where we check for the emptiness of CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX. Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix non-prefix buildsAlexandru Croitor2020-07-021-1/+1
| | | | | | | | | | QT_WILL_INSTALL was set to ON, because an incorrect comparison was done. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Change-Id: I201aa2a183563ce05077c36ac2ba3bd61cc827c0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix non-prefix build detection when CMAKE_STAGING_PREFIX is setJoerg Bornemann2020-07-011-4/+13
| | | | | | | | | | | | | | | | It wasn't possible to create a cross, non-prefix build with CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir and CMAKE_STAGING_PREFIX set to the qtbase build dir. This would be equivalent to configure -prefix /usr \ -extprefix ~/my/qtbase/build/dir Fix this by comparing the qtbase build dir against CMAKE_STAGING_PREFIX if it is set. We also have to adjust the QT_BUILD_DIR variable in a similar way. Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Support cross-compilation with qmakeJoerg Bornemann2020-06-291-7/+14
| | | | | | | | | | | | | When cross-compiling, we now create a target_qt.conf file that's to be used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf" projects can be cross-built against the cross-built Qt. We also create wrapper scripts for the host qmake to save the user from passing the -qtconf argument. Fixes: QTBUG-82581 Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Apply symbol visibility settings to Objective-C/C++ sourcesTor Arne Vestbø2020-06-251-0/+2
| | | | | | | | | | | | | | | Otherwise the Objective-C++ sources will be built with the default compiler visibility (visible), and then linked with moc-generated C++ sources that have the Qt overridden hidden visibility, resulting in linker warnings such as: ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o' to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility setting Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Improve sanitizer detectionAlexandru Croitor2020-06-151-0/+1
| | | | | | | | | | | | | | | The change fixes the labels to show up correctly in the configure summary. It also allows enabling the sanitizer via the feature flags, e.g. -DFEATURE_sanitize_address=ON. Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra so that repos built after qtbase have the same sanitizer options enabled. Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12 Fixes: QTBUG-84721 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove last traces of QT_BUILD_EXAMPLESKai Koehne2020-06-111-9/+1
| | | | | | | | Amends dc1dd51af3a35728235cb63a31b07ff76a652208 Task-number: QTBUG-84471 Change-Id: Ia525398aea4d90ac57c0f567ac8b48bf5ce80fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't add "d" suffix to MinGW debug librariesJoerg Bornemann2020-06-111-1/+9
| | | | | | | | | | To be in line with the qmake build we drop the "d" suffix for MinGW debug libraries unless the debug_and_release feature is enabled. Task-number: QTBUG-84781 Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't configure examples by defaultAlexandru Croitor2020-06-101-1/+1
| | | | | | | | | Users / developers usually configure a single example. The CI can still continue to explicitly configure and build all examples. Task-number: QTBUG-84471 Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make it possible to build tools when cross-compilingLeander Beernaert2020-06-021-1/+6
| | | | | | | | | | | | | | | | | | | This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Handle super build non-prefix install prefix correctlyAlexandru Croitor2020-04-171-2/+2
| | | | | | | | | | | | | | | | | The install prefix in such a case is the qtbase build dir, and not the qt6 top-level build dir. This caused issues with certain incorrect paths being generated, including a broken qt-cmake-standalone-test script, as well as upon reconfiguration determining that a non-prefix build should be installed. The fix for a non-prefix build is to check explicitly for the qtbase build dir. This works both for super and non-super builds. Task-number: QTBUG-83496 Change-Id: Ida2393176c4c81da767023ff48159afdedfb0a19 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Allow excluding tools and apps from the default 'all' targetAlexandru Croitor2020-04-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | Qt uses the qtNomakeTools() function to mark a directory which will not be built as part of the default target. This is especially important when cross-compiling (to iOS for example) because the build process might fail. The condition for not building these "GUI tool sub-directory projects" is the absence of the "tools" value in qmake's QT_BUILD_PARTS variable. Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true, it's equivalent to "tools" not being present in QT_BUILD_PARTS. Introduce qt_exclude_tool_directories_from_default_target(). It's the qmake counter part to qtNomakeTools(). Teach pro2cmake to generate it where appropriate. Change-Id: If2e5958d91847ab139af0e452608510286e73fa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-2/+2
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't build tests and examples by default on Android and iOSAlexandru Croitor2020-03-121-2/+2
| | | | | | Change-Id: Ia31733e2cadfb52d11426c40f3543bedc48342c4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Port most of the configure summary supportAlexandru Croitor2020-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Teaches configurejson2cmake about summaries / reports, so things like enabled features, configure sections, notes, etc. Add relevant CMake API for adding summary sections and entries, as well as configure reports. The commands record the passed data, and the data is later evaluated when the summary needs to be printed. This is needed, to ensure that all features are evaluated by the time the summary is printed. Some report and summary entries are not generated if they mention a feature that is explicitly exclduded by configurejson2cmake's feature mapping dictionary. This is to prevent CMake from failing at configure time when trying to evaluate an unknown feature. We should re-enable these in the future. A few custom report types are skipped by configurejson2cmake (like values of qmake CONFIG or buildParts). These will have to be addressed a case-by-case basis if still needed. Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix Ninja Multi-Config framework buildsAlexandru Croitor2020-03-061-0/+1
| | | | | | | | | | | | | | | | | | Depends on a new bleeding edge feature in as-of-yet unreleased CMake 3.18, that allows building macOS frameworks using the Ninja Multi-Config generator targeting more than one configuration. It uses the new CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG property which tells CMake to create properly named debug artifacts in the Multi-Config ninja file. Without it, both debug and release artifacts would have the same location (no _debug) postfix, so it would be unclear which file ends up being compiled as last (the debug or release variant). Change-Id: I3e10832551731a18317da8f9667d96cec3dc3028 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Port the 'debug_and_release' featureJoerg Bornemann2020-03-051-0/+3
| | | | | | | | This feature is read-only. It's controlled by the multi-config feature of CMake. It mainly exists for the qmake support. Change-Id: I322459598fe92568eda4d42319ded444537e95d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows doing debug_and_release builds with Ninja on all platforms. The "Ninja Multi-Config generator" is available starting with CMake 3.17. Desired configurations can be set via CMAKE_CONFIGURATION_TYPES. Possible values: "Release, Debug, RelWithDebInfo, MinRelSize". For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug". The first configuration is the 'default' configuration which is built when calling ninja with no arguments. To build all targets of a certain configuration use "ninja all:Release" or "ninja all:Debug". To build all targets in all configurations use "ninja all:all". Note that the first configuration influences which configuration of tools will be used when building the libraries for all configurations. In simple terms, when configured with -DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc is used by AUTOMOC. When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release" the debug version of moc is used by AUTOMOC. Framework builds and Ninja Multi-Config don't currently work together due to multiple bugs in CMake, which ends up generating an invalid ninja file with duplicate rules. There are also issues with placement of the debug artifacts. This will be handled in a follow up patch after CMake is fixed. Task-number: QTBUG-76899 Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add initial support for cross-building to iOSAlexandru Croitor2019-12-031-1/+14
| | | | | | | | | | | | | | | | | | | | | | Tested locally with the following configurations: - iOS device builds (arm64) - iOS simulator builds (x86_64) - iOS simulator_and_device builds (fat arm64 and x86_64 archives) All iOS builds currently require a custom vcpkg fork which contains fixes for building the required 3rd party libraries. qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2 have also been tested to build successfully. simulator_and_device builds are also supported, but require an umerged patch in upstream CMake as well as further patches to vcpkg. Task-number: QTBUG-75576 Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Rename / prefix all our private API functions with qt_Alexandru Croitor2019-11-141-1/+1
| | | | | | | | | | | Rename internal APIs like extend_target to qt_extend_target. Prefix apis with qt_ where required. Keep old names for compatibility until all their usages are removed. Change-Id: I9a13515a01857257a4c5be3a89253749d46a4f41 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Always build tests by default when building standalone testsAlexandru Croitor2019-11-131-0/+4
| | | | | | | | Amends 021c17c62f963a682c6a4b19f0c3d362c28a97ee Change-Id: I8181270ef7506eb5da4d3b43e105e100ed5581e4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A developer can pass either -DQT_NO_MAKE_TESTS=ON or -DQT_NO_MAKE_EXAMPLES=ON to exclude tests or examples from being built as part the default make target (when you write just make or ninja). With ninja, tests and examples can be built separately one by one, by typing $ ninja tst_foo or $ ninja example_bar Same can be done with the Makefile generator. $ make tst_foo All tests / examples can be built in one go by typing $ ninja tests/all or $ ninja examples/all With the Makefile generator unfortunately it's not as nice and is most likely an implementation detail, but it can still be done by running something like $ make -f CMakeFiles/Makefile2 tests/all or $ make -f CMakeFiles/Makefile2 examples/all Change-Id: I34f168b3ab41e952a21d3ace5634e25a9f41922e Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Make standalone tests build via top level repo projectAlexandru Croitor2019-11-081-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Add support for benchmark conversionLeander Beernaert2019-11-041-0/+11
| | | | | | | | | | | | | Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Pick the latest available C/C++ standard when compiling QtSimon Hausmann2019-10-171-5/+2
| | | | | | | | | | This maps the behavior of mkspecs/features/qt_common.prf and enables the use of C++17 for example in Android, where the toolchain supports it anyway. Change-Id: I41f4bdb160a3929e2fb78f36efb1ad5f2ad391a5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Include QtPlatformSupport as part of find_package(Qt6BuildInternals)Alexandru Croitor2019-09-271-3/+0
| | | | | | | | | | | This is needed because the ported over requires() clauses from qmake to CMake are executed before qt_repo_build(), which means that all the custom platform variables that we set (like LINUX, APPLE_OSX) need to be available immediately after finding BuildInternals. Change-Id: I7345b69edf72c266508846766e64f42c99862d1d Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Propagate BUILD_TESTING and BUILD_EXAMPLESAlexandru Croitor2019-09-061-0/+3
| | | | | | | | | | | | | | As with qmake, you configure with or without -nomake tests -nomake examples, and the choice is propagated to other repositories. Do the same for CMake. It's still possible to opt out to build one or the other by passing -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF on the command line, which takes precedence over the value saved to QtBuildInternalsExtra. Change-Id: If0fbfa938d88309e7969c9bacc8d0bf86548bf5e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 11:33:44 +0000