summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuildInternalsExtra.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Change license for .in filesLucie Gérard2024-03-051-0/+3
| | | | | | | | | | | | | According to QUIP-18 [1], all build system files should be BSD-3-Clause. The files in this patch are part of the build system. [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e Reviewed-by: Kai Köhne <kai.koehne@qt.io>
* CMake: Simplify default CMAKE_BUILD_TYPE logicAlexandru Croitor2024-01-261-38/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had four-ish locations where the CMAKE_BUILD_TYPE was force set. Twice in QtBuildInternalsExtra.cmake via qt_internal_force_set_cmake_build_type_conditionally(), depending on some conditions. This was executed right at find_package(Qt6 COMPONENTS BuildInternals) time. And twice in qt_internal_set_default_build_type() via qt_build_repo_begin() / qt_prepare_standalone_project() that goes through QtSetup.cmake. This was executed only if the relevant functions were called, rather than directly at find_package() time. The exact logic of which build type ended up being set was very confusing. Refactor the code to decide the build type in one single location when qt_build_repo_begin() / qt_prepare_standalone_project() are called, rather than directly at find_package() time. The actual logic when we override the build type depends on many factors: - when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's a multi-config build - when it's a multi-config build, don't set any CMAKE_BUILD_TYPE, use the value of CMAKE_CONFIGURATION_TYPES - when it's a qtbase build, compute a default unless an explicit value was given - the default is Debug if FEATURE_developer_build is ON - otherwise the default is Release - when it's a top-level build, only choose a build type for qtbase - when it's another repo build, use the original build type unless another was given explicitly (including in a top-level build) - when it's a standalone tests build - if qt is multi-config, the tests will be single config, due to various CI failure reasons, this hasn't changed - if qt is single config, use the original unless an explicit value was given - when it's a single standalone test build, use the original unless an explicit value was given To determine when an explicit CMAKE_BUILD_TYPE was given in contrast to when it was default initialized, we now have one single function that uses a few heuristics. The heuristics are needed because we can't reliably determine an explicitly given 'Debug' build on Windows, because CMake default initializes to that. The heuristics include: - checking whether CMAKE_BUILD_TYPE_INIT is different from CMAKE_BUILD_TYPE - checking what the CMAKE_BUILD_TYPE was before the first project() call when CMake default initializes - we save the previous value in the qt.toolchain.cmake file - also in QtAutoDetect during qtbase configuration - also when building the sqldrivers project - honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE As a result of the above changes, the build type will be set exactly zero or one times, for a particular build directory. Note that the configure script also has some logic on which CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake depending on whether -debug / -release / -debug-and-release / -force-debug-info were passed. But once the values are passed, CMake will honor them. Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec Pick-to: 6.7 Task-number: QTBUG-114958 Task-number: QTBUG-120436 Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Make sure to follow BuildInternals CMAKE_BUILD_TYPE on WindowsAlexandru Croitor2023-07-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | A regression was introduced in 48841c34d2e86a741ec9992b9704c0fa5973503c when configuring qtshadertools with -prefix -debug and no -developer-build. qtbase would have been built as Debug, but qtshadertools as release. This caused qsb.exe to link to a debug c++ runtime via QtCore, and a release one via QtShaderTools libraries and thus cause heap corruption crashes during runtime due to the mismatch. This happened because the check in cmake/QtSetup.cmake thought Debug was the default build type (nothing was specified on the command line) without knowing it was explicitly set BuildInternals. Set a variable when BuildInternals sets CMAKE_BUILD_TYPE and make sure QtSetup does not override it then. Augments 33af62db3747bb6fcb7490ef2d2abc5bb53925b6 Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Fixes: QTBUG-114958 Change-Id: I5e0a27b4d77512494c026dd911ec5757889a5a1a Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Introduce -no-vcpkg flag for disabling vcpkg detection/integrationAmir Masoud Abdol2023-06-271-0/+3
| | | | | | | | | | | | | | | | | Vcpkg detection is enabled by default, but we did not have a flag to disable it, and it was not showing up in config.summary either. By adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well as adding an entry to config summary indicating whether vcpkg is in use or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake command in order to disable the automatic vcpkg detection/integration. [ChangeLog][configure] vcpkg detection, and integration can be disabled by passing the -no-vcpkg flag to the configure command, or by passing `-DQT_USE_VCPKG=OFF` to the cmake command. Pick-to: 6.6 Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add -unity-build, and -unity-build-batch-size to configureAmir Masoud Abdol2023-02-091-0/+4
| | | | | | | | | | | If -unity-build-batch-size is not given, we default to CMake's default which is 8. In QtSetup.cmake, we explicitly set the default to avoid having it set to OFF in case it is missing, just to make sure that we don't get any unintended behavior. Task-number: QTBUG-109394 Change-Id: I19849e9baa507b64fb23847c740e20a7adc61b8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Propagate usage of WARNINGS_ARE_ERRORS when building reposAlexandru Croitor2022-11-021-0/+3
| | | | | | | | | | | | | | | | | When configuring a qtbase developer build, WARNINGS_ARE_ERRORS is set to ON and -Werror flags are added to the PlatformInternal targets. But the value of WARNINGS_ARE_ERRORS is not exported. This means that CMake code can't make decisions based on that variable when building other repos, and we now have such code with the new syncqt.cpp in qt_internal_target_sync_headers. Export the value of WARNINGS_ARE_ERRORS in QtBuildInternalsExtra.cmake.in. Fixes: QTBUG-108151 Change-Id: I5de2633fcb1f20fead7d436c201852424e726842 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Implement the batch_tests featureMikolaj Boc2022-08-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | An approach of test batching (joining multiple tests into a single binary) has been taken, due to long linking times/binary size on certain platforms, including WASM. This change adds a new feature 'batch_test_support' in Qt testlib. Based on the value of the feature, test batching may become enabled with the -batch-tests switch. Batching works for every target added via qt_internal_add_test. When first such target is being processed, a new combined target for all of the future test sources is created under the name of 'test_batch'. CMake attempts to merge the parameters of each of the tests, and some basic checks are run for parameter differences that are impossible to reconcile. On the C++ level, convenience macros instantiating the tests are redefined when batch_tests is on. The new, changed behavior triggered by the changes in the macros registers the tests in a central test registry, where they are available for execution based solely on their test name. The test name is interoperable with the names CMake is aware of, so CTest is able to run the tests one by one in the combined binary. Task-number: QTBUG-105273 Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Build minimal subset of tests for Android multi-ABI Qt buildsAlexey Edelev2022-08-021-0/+2
| | | | | | | | | Add an option to limit the number of tests for building and testing Android multi-ABI configurations in CI. Currently only Core tests supposed to run. Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix prefix propagation for relocated Qt installationsJoerg Bornemann2022-07-131-7/+6
| | | | | | | | | | | | | | Consider qtbase built with CMAKE_STAGING_PREFIX=/foo on Windows. If /foo was moved to /bar, non-qtbase repositories did get a staging prefix with drive letter assigned. This is undesirable when DESTDIR is used on installation. Change the implementation of qt_internal_new_prefix to remove the drive letter from the "new prefix" if the "old prefix" did not have a drive letter. Change-Id: I6fb17e690b264920b0dd4204e3b3c30794c7e76e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Propagate qtbase's original staging prefix to other Qt reposJoerg Bornemann2022-07-111-14/+27
| | | | | | | | | | | | | | | | | | | | | | If qtbase was configured with CMAKE_STAGING_PREFIX set to a path without drive letter on Windows, we must ensure that this exact staging prefix is propagated to non-qtbase repos. We already had code that does this for CMAKE_INSTALL_PREFIX. But since 9a74d94ff5fa63bfb23dcad1209e2844ef39908b we build our cross-built packages with CMAKE_STAGING_PREFIX instead of CMAKE_INSTALL_PREFIX. Move said code into a function and use it for CMAKE_STAGING_PREFIX too. This fixes Android non-qtbase release libraries not being stripped in our Windows Android packages. This amends commit 037fd545c485e73ac68377a264c84208592dc74f. Fixes: QTBUG-104827 Pick-to: 6.2 6.3 6.4 Change-Id: I909f7f39bd0ef7b559619b69f756c042d6c528b0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Support overriding CMAKE_BUILD_TYPE per-repo or testJoerg Bornemann2022-01-211-0/+37
| | | | | | | | | | | | | | | | | | | | | One might want to build qtbase in Release, but qtsvg or some test in Debug mode. Before if qtbase was configured as Release, there was no way to override that. Now we try to detect whether a custom build type was specified to qt-cmake / qt-configure-module / qt-cmake-standalone-test / qt-internal-configure-tests Note mixing won't work on Windows due to different C/C++ runtimes. Also, now we don't force set a single build type when a multi config generator is used as well as one opts out via the QT_NO_FORCE_SET_CMAKE_BUILD_TYPE variable. Pick-to: 6.2 6.3 Change-Id: I6dc4325087ff7f905ad677d87b0267e2f3e4693f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Propagate qtbase's CMAKE_STAGING_PREFIX to Qt modulesJoerg Bornemann2022-01-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | When qtbase is configured with CMAKE_STAGING_PREFIX set, then Qt modules built against this qtbase should also get CMAKE_STAGING_PREFIX by default. Like CMAKE_INSTALL_PREFIX in regular builds, this prefix will be determined by the location of QtBuildInternalsExtra.cmake to support building Qt modules against an installer-provided Qt. CMAKE_INSTALL_PREFIX on the other hand must be exactly the value that was provided when building qtbase. If CMAKE_STAGING_PREFIX is specified by the user, honor it. To opt out of automatically setting CMAKE_STAGING_PREFIX, set QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX to ON. Remove the old code that was supposed to set CMAKE_STAGING_PREFIX. Pick-to: 6.2 6.3 Fixes: QTBUG-99666 Change-Id: I20edef54c102ca9784fcdef0decf0bd83266ae11 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix default install prefix of top-level non-developer buildsJoerg Bornemann2021-11-081-1/+3
| | | | | | | | | | | | | | | A top-level non-developer build is supposed to default to a prefix like "/usr/local/Qt-6.3.0". That wasn't the case. In QtSetup.cmake we check CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, set CMAKE_INSTALL_PREFIX and did the same thing later in QtBuildInternalsExtra.cmake, with a different value. Make sure we run the latter code only in per-repo builds. Pick-to: 6.2 Fixes: QTBUG-98087 Change-Id: I4a1291dfd126aa11c21d69809f2cf7b075c98d2e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow opting out of building examples as ExternalProjectsAlexandru Croitor2021-09-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Save QT_BUILD_BENCHMARKS and other info in BuildInternalsExtraAlexandru Croitor2021-08-171-0/+7
| | | | | | | | | | So that those values are used when configuring other repos in a per-repo build arrangement. Pick-to: 6.2 Change-Id: I5ff86260116c52afc87d7fcd5cbd047fcb9dde22 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enforce minimum CMake version in user projectsAlexandru Croitor2021-08-041-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces new behavior to error out when configuring user projects if the CMake version used is too old for Qt to work with. The main motivator is the requirement of new CMake features to ensure object libraries are placed in the proper place on the link line in static builds. The minimum CMake version is computed based on whether Qt was configured as shared or static libraries. At the moment the required versions for building and using Qt are the same. The minimum versions are defined in qtbase/.cmake.conf in the following variables QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC Qt Packagers can disable the version check when configuring Qt by setting QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT. In this case it is the packagers responsibility to ensure such a Qt works correctly with the specified CMake version. User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT to disable the version check. Then it's the project's developer responsibility to ensure such a Qt works correctly. No official support is provided for these cases. Implementation notes. The versions required to build Qt are stored in QtBuildInternalsExtra.cmake whereas the versions required to use Qt are stored in a new QtConfigExtras.cmake. Also the policy range variables stored in QtBuildInternalsExtra.cmake are now regular variables instead of cache variables, to properly allow overrides per-repository. Some renaming of functions and variables was done for a bit more clarity and easier grep-ability. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: add an option to enable or disable versioned hard linkLi Xinwei2021-05-131-0/+4
| | | | | | | | | | | The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it is set to ON. Users can set this option to OFF to disable versioned hard link. Pick-to: 6.1 Fixes: QTBUG-93636 Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0 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>
* Fix DESTDIR handling on Windows for Qt modules != qtbaseJoerg Bornemann2021-04-191-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | On the CI system, we build qtbase with CMAKE_INSTALL_PREFIX set to a path without a drive letter to support DESTDIR when installing. Other Qt modules are built without CMAKE_INSTALL_PREFIX set. The Qt6BuildInternals package provides a default value. Since commit e6527e2f73663205a0f36feac5a7feda47fba152 this default prefix is calculated from the current installation location. This default prefix however has a drive letter, breaking DESTDIR support. Broken DESTDIR support in this case means for Android that file(INSTALL) can properly install but stripping will silently fail. We now compare the "real path" of the original prefix from qtbase and the calculated prefix. When they're equal, we use the original CMAKE_INSTALL_PREFIX. Fixes: QTBUG-92890 Change-Id: I96fb0655e02c5c695722b7e01a32e209cbdea4cc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 15b26935fca4ab14298abdcc70b3cb15b6cca195) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix CMAKE_INSTALL_PREFIX when building against installer-provided QtJoerg Bornemann2021-03-111-1/+1
| | | | | | | | | | | | | | | | When building a module against an installer-provided Qt, CMAKE_INSTALL_PREFIX would default to /home/qt/work/install, which is the install prefix of our packaging machines. Do not hard-code the install prefix in QtBuildInternalsExtra.cmake but use the one that is calculated from the location of QtBuildInternalsExtra.cmake. Pick-to: 6.1 Fixes: QTBUG-90449 Fixes: QTBUG-91475 Change-Id: I39f214efb18796a89f00a171ef190c547bba5c0a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Name QT_NO_MAKE_*/BUILD_* variables consistentlyJoerg Bornemann2020-11-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix CMAKE_INSTALL_PREFIX assignment in QtBuildInternalsExtraJoerg Bornemann2020-07-131-1/+1
| | | | | | | | The prefix value must be surrounded by double quotes in case it contains whitespace. Change-Id: I393c57368d7a255f5042e363405071ef042afc18 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix failing standalone tests on WindowsAlexandru Croitor2020-05-011-0/+8
| | | | | | | | | | | | | | | Due to the install prefix being changed for standalone tests, the correct $qt_prefix/bin folder was not added to the PATH environment variable when running tests. Make sure to always include the the original qt install prefix, even if a different install prefix is specified when configuring standalone tests. Amends 39090ea15c41eded8a233ec2633c0c657280297c Change-Id: I22aab732bb2bb679074a811d28d8209e1d535df3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Propagate BUILD_TESTING and BUILD_EXAMPLESAlexandru Croitor2019-09-061-0/+4
| | | | | | | | | | | | | | 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
* Export architecture config test variablesLeander Beernaert2019-08-141-0/+3
| | | | | | | | | Export the architecture configuration variables from QtBase. There are other modules that require access to this information in order to enable certain features (e.g: qml_jit in QtDeclarative). Change-Id: If2c7f29ccb1c0b0a0db3d78ad133a2a6be12b5ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Ugly fix for handling QT_SOURCE_TREEAlexandru Croitor2019-07-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf. In qtbase, it's used throughout various projects to find cpp sources when building standalone tests (among other things). Everything works fine with qmake, because even if qmake is invoked on the tests subfolder, qmake searches up the source directory tree until it finds a .qmake.conf file, and uses that. When building qttools with qmake, the qdoc project expects to have a QT_SOURCE_TREE value, but it's not actually set in the qttools/.qmake.conf file, so the generated include paths that use that value are incorrect. Curiously the build still succeeds. Now in CMake land we replaced QT_SOURCE_TREE with CMAKE_SOURCE_DIR, but that does not work properly when doing a standalone tests build, because the project in that case is the tests one, and not the qtbase one, so configuration fails in a developer build when trying to configure some private tests. So far I've found that only qtbase actively uses this value. A temporary fix is to save the qtbase source directory into a QT_SOURCE_TREE variable inside the generated BuildInternalsExtra.cmake file. The pro2cmake script is changed to handle presence of QT_SOURCE_TREE in a qrc file path. This is handled by finding the location of a .qmake.conf file starting from the project file absolute path. This is needed to stop the script from crashing when handling the mimedatabase test projects for example. The change also regenerates the relevant failing test projects, and thus standalone tests (when doing developer builds aka private_tests enabled) now configure and build successfully. Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix non-prefix builds for non qtbase reposAlexandru Croitor2019-07-221-0/+4
| | | | | | | | | | | | | | | | QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Generate QtBuildInternalsExtra at conftimeKevin Funk2019-06-051-0/+17
... using configure_file. Change-Id: Ibe3522c33e20a86c454b23919547775624f84755 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 01:57:37 +0000