summaryrefslogtreecommitdiffstats
path: root/cmake/QtSetup.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Ensure top-level builds are affected by our chosen log levelAlexandru Croitor2022-06-131-11/+15
| | | | | | | | | | | | This will hide the configuration summary and cmake feature summary and found packages output upon reconfiguration. Task-number: QTBUG-104128 Change-Id: I42270b99e45076052ec176df4652661cae10ac0c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io> (cherry picked from commit b3d0325a8dca56d3163451a417edfe6015a4ffe0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix initialization of QT_BUILD_TOOLS_BY_DEFAULTJoerg Bornemann2022-05-111-0/+8
| | | | | | | | | | | | | | ...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON. When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set QT_FORCE_BUILD_TOOLS. But this happened too late: after the initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on QT_FORCE_BUILD_TOOLS. This amends commit acfbe3b7795c741b269fc23ed2c51c5937cd7f4f. Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: also allow building tools when found elsewhere in host buildsThiago Macieira2022-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, this was only supported when cross-compiling, but that's an unnecessary limitation. Instead, make it possible to build the "host" tools (notably qmake) even when they've been found elsewhere due to QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH. The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to ON is useful for developers who touch content that ends up in the bootstrap library. QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of QT_FORCE_BUILD_TOOLS. [ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from a host Qt even for a non-cross build and still build the tools. Fixes: QTBUG-99683 Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: An -extprefix -developer-build should install by defaultAlexandru Croitor2022-04-191-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if -extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX) -developer-build (FEATURE_developer_build) were specified, but -prefix (CMAKE_INSTALL_PREFIX) was not, the build system would set the CMAKE_INSTALL_PREFIX to the qtbase build dir. Then, if targeting desktop, this would be considered a non-prefix build (ninja install would refuse to work), whereas in a cross-build it would be considered an installable build. In both cases though, the rpath of installed binaries would point to the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the qtbase build dir). This is quite confusing behavior, in more than one way. Change the build system to consider that an explicit -extprefix should cause Qt to always be installed, even if -developer-build is specified. This means the installed rpaths and on-device install prefix (CMAKE_INSTALL_PREFIX) will now use the default computed install prefix, e.g. /usr/local/Qt It also means that to get a non-installable developer + custom staging and install (on-device) prefix build, users will have to be explicit and set all the options -extprefix ~/qt/qtbase_build_dir -prefix /usr -developer-build Pick-to: 6.2 6.3 Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow no install + custom on-device prefix for desktop buildsAlexandru Croitor2022-04-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Make configure less verbose by defaultAlexandru Croitor2022-03-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Only show the more verbose configure output when configuring with -developer-build (which matches --log-level=STATUS) Otherwise in a non-developer build, restrict the output to NOTICE+ message (includes WARNINGs and ERRORs). Developers can still pass a custom log level when configuring. For example -DCMAKE_MESSAGE_LOG_LEVEL=STATUS or --log-level=STATUS. The former method will be cached, while the latter is only applied to the current configure invocation. Also show the build instructions hint message only when configuring for the first time. [ChangeLog][CMake][configure] The configure output verbosity of non developer-builds of Qt is now reduced by default. Pass "-- --log-level=STATUS" to configure to make it verbose again. Pick-to: 6.2 6.3 Change-Id: I7583a9c92142e0b1d7c5411b06403f40d8ebaf20 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* configure: CMake: Add -no-prefix optionAlexandru Croitor2022-02-241-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new -no-prefix option that can be used to build Qt without having to install it. Currently, -no-prefix is already implied by -developer-build, but -developer-build also implies -warnings-are-errors and -feature-private-tests, which not everyone might want to use. Some Qt builders likely use -developer-build for the no-prefix behavior, hence we introduce a standalone -no-prefix option to offer a nicer user experience without -Werror and friends. Previously it was possible to achieve the same by specifying -prefix $PWD, but that relies on $PWD expanding property in the used shell. The new -no-prefix doesn't depend on the type of the shell and is shorter to type. Internally this gets passed by configure as -DINPUT_no_prefix=yes to CMake, and transformed into a -DQT_FEATURE_no_prefix=ON feature. The feature also gets automatically auto-detected to ON if developer-build is set, -prefix is either unset or $PWD. CMake code should still query QT_WILL_INSTALL to decide whether files need to be installed or not. As a drive-by, we now also export QT_FEATURE_developer_build to be available for querying during configuration of other repos (previously it was only possible to query FEATURE_developer_build). Pick-to: 6.2 6.3 Change-Id: Iaa6c8d8ae2b736282e9949d2a5d7f412e290a253 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Read QT_HOST_PATH from the environment tooJoerg Bornemann2022-02-241-1/+2
| | | | | | | | | | | For cross-compiled conan packages we need conan to export QT_HOST_PATH as an environment variable. The Qt build now picks up this environment variable if no QT_HOST_PATH cache variable was specified. Pick-to: 6.2 6.3 Change-Id: I0c3e15e82842061d5db81949ffcc1c240f6ed6a4 Reviewed-by: Iikka Eklund <iikka.eklund@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Assign proper postfixes in multi-config buildsAlexandru Croitor2022-02-091-2/+29
| | | | | | | | | | | | | | | | | | | | | | In a single-config build on Linux, we usually don't want a debug postfix in library names (as opposed to Windows/macOS). But when doing a multi-config build on Linux, assigning no postfixes causes CMake to generate rules for a single config only, the first one specified in CMAKE_CONFIGURATION_TYPES. This leads to being unable to build all configurations from the same build.ninja file as well as other obscure issues like race-conditions when generating prl files. To address this, when doing a multi-config build, always assign a postfix for each config except the first release-like one, while preserving the existing rules we had for debug postfix names. Pick-to: 6.2 6.3 Fixes: QTBUG-100493 Change-Id: Ie9c88e074abdcf2961d7b3dee19a5694292717b8 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Temporarily disable building external examples in prefix buildsAlexandru Croitor2022-02-031-1/+9
| | | | | | | | | | | | | | | | | | | There are issues when building examples as external projects in the CI in child repos like qtsvg. QEMU configurations fail to find some CMake Config files, Windows configs fail to find libraries. Until these issues are fixed, build examples in-tree (without using external projects) like we did before. Temporarily disables 98c89c8cc1c5ceb4bfbb5f5ed6c96ecdbab99afa Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ia4b39812b27cfde5f5a103fd39cc1cb032842643 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Build examples as ExternalProjects in prefix buildsAlexandru Croitor2022-02-011-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 01:20:33 +0000