summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuildInternals
Commit message (Collapse)AuthorAgeFilesLines
* Fix top-level build repository targetsJoerg Bornemann2021-04-191-9/+10
| | | | | | | | | | | | | The directory-level targets missed the first level of sub-targets. E.g. `qtbase_qmake` did not have a dependency to `qmake`. Fix qt_build_internals_get_repo_targets to first grab all targets of the subdirectory and then recurse. Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 82f8519b827ba7fd89f8168632461f47b09605a7) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Fix autotest config in cross-compiled prefix buildEirik Aavitsland2020-12-171-1/+5
| | | | | | | | | | | qt-cmake-standalone-test would be looking for the config files under the target machine install prefix instead of under the staging prefix on the build host. Change-Id: I29850af6d8fe502f4944f689ec10539d17ccdcb9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit e26d2865a718cecd08233e84673c67c5ca3bc765) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Offer to build manual tests through QT_BUILD_MANUAL_TESTSAleix Pol2020-12-081-2/+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 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 9d831491334e75f8ccc691edaeb173af81ab80ac) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Add extra targets to run single benchmark using CMake generatorAlexey Edelev2020-12-071-0/+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 Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 61d5b019727dd1c06366205cb307a2a928a2a29c) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 3859f15ec9fd333089e6eb1152a76592cd5f83c0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Rename QtBuildInternalsAndroid.cmake to QtAndroidHelpers.cmakeJoerg Bornemann2020-11-242-225/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...and include it in QtBuild.cmake. Commit e8d8b1a5e4c added two different code paths to include QtBuildInternalsAndroid.cmake. This was needed, because: In a top-level build, we must not include files that are not yet installed. We have the source tree available, and "${QT_SOURCE_TREE}/cmake" is in CMAKE_MODULE_PATH. We can use the "module syntax" of the include() command. In a per-repository build, when building against an installed qtbase, we must not include files of the source tree, because that's not guaranteed to be available. However, Qt6BuildInternalsConfig.cmake is installed, and we can directly include QtBuildInternalsAndroid.cmake, which is right next to it. We can circumvent this whole issue by moving the Android-related functions out of the Qt6BuildInternals package and including it in QtBuild.cmake. Task-number: QTBUG-88718 Change-Id: I5192ba19bb77952505c20d053d7285f798d16ac5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 0274daf30779ba08fc708247a3e645fd44980280) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix Android non-top-level build against qtbaseJoerg Bornemann2020-11-231-1/+6
| | | | | | | | | | | | | | | | | Commit 9e0fb9c4fbe7a11c09a70d7ea1be97405c6bf0f8 introduced build failures in non-top-level builds when building Qt modules against qtbase. This was observed on in the CI for CentOS. Partly revert above commit by taking the old code path for non-top-level builds. Fixes: QTBUG-88718 Change-Id: I8926e1e4628ec5bdcea99e10497c1f65c10d072d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 510186a218e63c88100efc38cb1611f122f94570) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Name QT_NO_MAKE_*/BUILD_* variables consistentlyJoerg Bornemann2020-11-201-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit fb21a5ce1a5831fab2af5e4d301600d6a6211e5d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Toplevel builds: Add utility toplevel targets for each moduleVolker Hilsheimer2020-11-201-0/+47
| | | | | | | | | | | | Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 08f46bb40075778e89ba9aed3cef53d990852022) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix Android top-level prefix buildJoerg Bornemann2020-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | During a top-level prefix build, while configuring qtsvg, Qt6BuildInternalsConfig tries to include QtBuildInternalsAndroid.cmake but such files are not copied by qt_copy_or_install() at configure time. We need to use the "module" form of include() to take CMAKE_MODULE_PATH into account. Then QtBuildInternalsAndroid.cmake can be loaded from the source tree. The include's current form was introduced in commit 3cb9ee3a5b36e2c10dbaf1564852472e7e02a1ae without further explanation. Assuming an accidental change. Task-number: QTBUG-88460 Change-Id: If06ac715fae3c2bebbeffca44b7e07265ffb0f71 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 9e0fb9c4fbe7a11c09a70d7ea1be97405c6bf0f8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Disconnect docs installation targets from generation targetsJoerg Bornemann2020-11-061-4/+0
| | | | | | | | | | | | | | | | | "ninja install_docs" should not run the "docs" target, because with the usual workflow ninja docs ninja install_docs the documentation would be built twice. That of course means that "ninja install_docs" will fail if "ninja docs" wasn't run before. Analogous for html_docs, qch_docs, the repository-level and module-level documentation targets. Change-Id: I8ad83602dd393b5afc79a19ab3d395987c889d0d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix top-level documentation install targetsJoerg Bornemann2020-11-061-0/+4
| | | | | | | | | | | | | | | | | | | | | The following targets did not do any actual installation: install_docs, install_html_docs, install_qch_docs, plus their repository-level counterparts. Add the following dependencies: install_html_docs --> install_html_docs_<repo> --> install_html_docs_<module> Analogous for qch. The install_docs target already triggers install_html_docs and install_qch_docs. Analogous for install_docs_<repo>. Fixes: QTBUG-86738 Change-Id: I3468e000e050e2787a859e61d40161f5459cb351 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Bump the minimum required CMake version to build Qt to 3.18Alexandru Croitor2020-11-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new function that returns the minimum CMake version required to build Qt. Pass that value to cmake_minimum_required() when building qtbase and its standalone tests. The minimum supported CMake version is read from qtbase/.cmake.conf and its value should be updated when the need arises. It's the main source of truth for all repos. Provide a way to lower the minimum CMake version at configure time by passing a value via QT_FORCE_MIN_CMAKE_VERSION. This is not an officially supported way of building Qt. If the specified version is lower than Qt's supported minimum, show a warning. Nevertheless the option is useful for testing how Qt builds with a different minimum CMake version due to different policies being enabled by default. Issue warnings for CMake versions that are higher than the minimum version but are known to cause issues when building Qt. A counterpart change is needed in qt5 to ensure the minimum CMake version is set at the proper time for top-level builds. Ideally we would use the same 'check the CMake minimum version` code in all our repositories, but that will cause lots of duplication because we can't really find_package() the code and doing something like include(../qtbase/foo.cmake) hardcodes assumptions about repo locations. So for now we don't bump the minimum version in child repo cmake_minimum_required calls (qtsvg, qtdeclarative, etc). Instead we record both the minimum supported version and the computed minimum version (in case a different version was forced) in QtBuildInternalsExtra.cmake. Then we require qtbase's computed min version in qt_build_repo_begin(). This won't set policies as cmake_minimum_required would, but at least it propagates what minimum CMake version should be used for child repos. We might still have to bump the versions in child repos at some point. Task-number: QTBUG-88086 Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Re-work documentation targetsJoerg Bornemann2020-10-281-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The top-level prepare_docs target is supposed to run before the generate_docs target. The repository-level targets like prepare_docs_qtbase now also run before their respective generate targets. To achieve that, several intermediate targets had to be introduced. The dependencies for top-level generate_docs look like this: /--> generate_top_level_docs_Core --\ generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs \--> ... --/ The dependencies for repo-level generate_docs_<repo> look like this: /--> generate_repo_docs_Core generate_docs_qtbase ---> generate_repo_docs_Gui \--> ... generate_repo_docs_Core --\ generate_repo_docs_Gui -----> prepare_docs_qtbase ... --/ Analoguous for qch_docs. And last but not least, the module-level generate_docs_<module> depends on prepare_docs_<module>, just like before. The strangely named top-level install targets have been renamed to install_html_docs, install_qch_docs and install_docs. The html_docs target is now merely an alias for generate_docs. Apart from prepare_docs, the top-level targets do not depend on the repository-level targets anymore. Targets that are just an alias (docs, install_docs, ...) have been re-defined to depend just on the respective top-level targets. Fixes: QTBUG-87758 Change-Id: I24466d3a252d518a30a2064bf876be881c46231f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix handling of rpaths for tests with CMAKE_STAGING_PREFIXAlexandru Croitor2020-10-261-0/+12
| | | | | | Task-number: QTBUG-86053 Change-Id: I2f368d9dc2d871b67bd6261aadd8ef4c1dd1ae54 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add convenience custom targets to build Qt pluginsAlexandru Croitor2020-10-221-0/+10
| | | | | | | | | | | | | | Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Refactor optimization flag handling and add optimize_fullAlexandru Croitor2020-10-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a bunch of helper functions to manipulate compiler flags and linker flags for the CMAKE_<LANG>_FLAGS_<CONFIG> and CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG> CMake variables. These variables can be assigned and modified either in the cache or for a specific subdirectory scope, which will apply the flags only to targets in that scope. Add qt_internal_add_optimize_full_flags() function which mimics qmake's CONFIG += optimize_full behavior. Calling it will force usage of the '-O3' optimization flag on supported platforms (falling back '-O2' where not supported). Use the function for the Core and Gui subdirectories, to enable full optimization for the respective Qt modules as it is done in the qmake projects. To ensure that the global qmake-like compiler flags are assigned eveywhere, qt_internal_set_up_config_optimizations_like_in_qmake() needs to be called after Qt global features like optimize_size and optimize_full are available. This means that qtbase and its standalone tests need some special handling in regards to when to call that function. Task-number: QTBUG-86866 Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* By default don't try to use pkg-config when targeting AndroidAlexandru Croitor2020-09-281-1/+1
| | | | | | | | | | It causes issues in our Windows CI, because the strawberry perl pkg-config is found. And even that one is unusable, due to a bug in CMake which is tracked at https://gitlab.kitware.com/cmake/cmake/-/issues/21239 Change-Id: I58816195d35459e8a44c923399c35a4956c222a2 Reviewed-by: Simon Hausmann <hausmann@gmail.com>
* CMake: Turn off pkg_config_enabled if pkg_config is not foundAlessandro Portale2020-09-091-7/+28
| | | | | | | | | | | | | | | The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Implement configure -optimize-debugJoerg Bornemann2020-08-201-1/+3
| | | | | | Task-number: QTBUG-85373 Change-Id: I3aba1fcf96e36544dd75a5e6adc5f770a9a45726 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Adjust compiler flag optimizations to qmake mkspec onesAlexandru Croitor2020-08-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are inconsistencies in the default optimization flags added by CMake across configurations like Release and RelWithDebInfo. In particular Release uses -O3, whereas RelWithDebInfo uses -O2, as well as usage of /INCREMENTAL in release configs with MSVC, etc. To make sure that the Qt 6 binaries built with CMake are consistent across configs, as well as consistent with the flags we used when building Qt 5 with qmake, add a horrible search and replace mechanism to replaces the CMake flags with what our mkspecs indicate to use. Ideally this would be done by providing custom CMake toolchain files for each platform we support, and we might revisit that later if the need really arises. To implement the replacing, we first need the flags that should be added. Port the QMAKE_CFLAGS_OPTIMIZE variables to CMake, which is done in QtCompilerOptimization.cmake. Then a new function called qt_internal_set_up_config_optimizations_like_in_qmake will look for any kind of optimization flags set in the CMAKE_<LANG>_FLAGS_<CONFIG> style variables, remove them, and add the appropriate flags that qmake mkspecs provide. On some platforms (like Windows MSVC) the function also alters the linker CMAKE_${TYPE}_LINKER_FLAGS_<CONFIG> style variables. The mechanism allows opting out of this replacing by setting the QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS value. It also allows opting into removal of flags for custom configs by providing QT_ADDITIONAL_OPTIMIZATION_FLAG_CONFIGS. It's only removal, because we wouldn't know what kind of config it is, and thus what flags to add. The currently modified configs are: Release, RelWithDebInfo, MinSizeRel, Debug aka the usual default CMake provided ones. The mechanism is only applied to C-like languages. ASM is not handled to be on the safe side due to not knowing what kind of compiler flags the platform assembler might take. It's also important to skip RC on MSVC platforms. Task-number: QTBUG-85992 Change-Id: I3712d5cd5a34fceab54f56a6fa46b4e678952362 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake Build: Disable pkg-config for QNXCristian Adam2020-08-191-1/+1
| | | | | | | | QNX doesn't come with pkg-config support. Task-number: QTBUG-83202 Change-Id: I2ac0c014a071b83ef9a2d8114bae0e9ff9b3b422 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix configuration of CMake tests in-build-treeAlexandru Croitor2020-07-201-5/+11
| | | | | | | | | | | | Qt6 package was not found the tests were configured in-tree as opposed to standalone tests. Use the same trick we do for building examples in-tree. Specify the path to the build tree packages, and don't create targets. Amends 96e3ee06598d00e7155f3f8574759ea658a134e5 Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix various issues with the Android buildAlexandru Croitor2020-07-091-2/+1
| | | | | | | | | | | | | | | | | | | Certain resources and compiled jar files have to be copied into the non-prefix build dir location. They were previously only installed, which doesn't do anything in a non-prefix build. Change pro2cmake to generate code that places the compiled java jars into QT_BUILD_DIR, so that non-prefix builds work. Place the module dependencies xml files into lib folder in non-prefix builds. Don't special case the output and install location of the Android QPA plugin. Task-number: QTBUG-85399 Change-Id: I4ac9d3929ea8ecc95ec99a77e621ad2121b68832 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't use libraries in /usr/local by default on macOSAlexandru Croitor2020-06-291-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Add meta-target host_tools to easily build just the toolsAlexandru Croitor2020-06-261-0/+7
| | | | | | | | | | | A developer could write 'ninja host_tools' to build the qtbase tools and their dependencies, and then configure another cross-compiling build dir pointing to the previous host build. This shortens the workflow for cross-building when working in qtbase. Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't reset install prefix upon standalone test reconfigurationAlexandru Croitor2020-06-081-12/+4
| | | | | | | | | | | | | | | | | | | | CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the first configuration, but because QtBuildInternalsExtra sets the CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would stop setting the fake install prefix. After some further consideration, there's no need to set the local fake prefix conditionally, we can always do it (unless explicitly opted out). This makes sure that a reconfiguration of a test doesn't suddenly install into the Qt prefix again. Amends 37b132cd4e081821ddc261d24abe8f914123547a Task-number: QTBUG-84346 Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* cmake: quote paths to prevent issues when no install prefix is setJean-Michaël Celerier2020-06-051-1/+1
| | | | | Change-Id: Ifa7f1ef70c4893e10cb4ce9a54d8a0806d19be93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix standalone tests to work properly on reconfigurationAlexandru Croitor2020-06-042-17/+25
| | | | | | | | | | | | | | | | | And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 the setup for html_docs and qch_docsVenugopal Shivashankar2020-04-301-2/+2
| | | | | | | | | | | Traditionally, these make targets generated HTMLs and QCH only. This change fixes the dependency for these targets to ensure that behavior. Fixes: QTBUG-83877 Change-Id: Ic7c8afe5853d33fc4cc4cfd996f87e5f65df31ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* CMake: Fix usage of correct install prefix for standalone testsAlexandru Croitor2020-04-301-2/+15
| | | | | | | | | | | Previously configuration of standalone tests might have failed due to CMake trying to create files in the /usr/local default prefix. Make sure to use a fake prefix in the binary dir instead, unless another prefix is explicitly specified. Change-Id: Icfcb32285aa5596abf1a918396b26673880a8d27 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow sqldriver plugins to be built as standaloneLeander Beernaert2020-04-241-0/+8
| | | | | | | | | | | | | This patch allows all the sqldrivers to be built as a standalone project. It is not possible to build each plugin separately due to the configuration features definition being located in the sqldriver's folder CMakeLists.txt. In other words, the project needs to be generated from the src/plugins/sqldrivers/CMakeLists.txt file. Fixes: QTBUG-82962 Change-Id: If41c7e3827589391830a894a9c998d2e56239562 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add qt6_add_plugin public APILeander Beernaert2020-04-221-0/+1
| | | | | | | | | | | | | | | This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make sure not to use the Qt prefix for standalone testsAlexandru Croitor2020-04-172-0/+19
| | | | | | | | | We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle automatic rpath embedding correctlyAlexandru Croitor2020-04-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using CMAKE_INSTALL_RPATH to embed an absolute path to prefix/libdir into all targets, use the more sophisticated aproach that qmake does. For certain targets (modules, plugins, tools) use relative rpaths. Otherwise embed absolute paths (examples, regular binaries). Installed tests currently have no rpaths. On certain platforms rpaths are not used (Windows, Android, iOS / uikit). Frameworks, app bundles and shallow bundles should also be handled correctly. Additional rpaths can be provided via QT_EXTRA_RPATHS variable (similar to the -R option that configure takes). Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF or QT_DISABLE_RPATH=ON. Note that installed examples are not relocatable at the moment (due to always having an absolute path rpath), so this is a missing feature compared to qmake. This is due to missing information on where examples will be installed, so a relative rpath can not be computed. By default a Qt installation is relocatable, so there is no need to pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R . Relative rpaths will have the appropriate 'relative base' prefixed to them (e.g $ORIGIN on linux and @loader_path on darwin platforms). There is currently no support for other platforms that might have a different 'relative base' than the ones mentioned above. Any extra rpaths are saved to BuildInternalsExtra which are re-used when building other repositories. configurejson2cmake modified to include correct conditions for the rpath feature. It's very likely that we will need a new qt_add_internal_app() function for gui apps that are to be installed to prefix/bin. For example for Assistant from qttools. Currently such apps use qt_add_executable(). The distinction is necessary to make sure that relative rpaths are embedded into apps, but not executables (which tests are part of). Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Autodetect Objective-C support only on macOSAlexandru Croitor2020-04-071-1/+6
| | | | | | | | | | | | On Android, check_language() reports that the languages are supported, but enable_language fails afterwards. On Linux it causes issues with the PCH. The PCH file might contain a Clang pragma, even though the C++ compiler is GCC. Presumably due to finding a Clang Objective-C compiler. Change-Id: I1b4c54459772c089e7f6350872c87af52ad72a37 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Adjust PCH support for multi-arch iOS buildsAlexandru Croitor2020-04-031-0/+18
| | | | | | | | | | | | | | | | | | Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Provide script to configure and build one or more testsAlexandru Croitor2020-03-232-3/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add global / top-level docs targetsAlexandru Croitor2020-03-181-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Fix incorrect argument in QtBuildInternalsAndroidAlexandru Croitor2020-03-121-2/+2
| | | | | | | | Uncovered while building qtdeclarative. Change-Id: If1a36f2640a3a5d765e7ca74b0ba1d39ef2a18f0 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-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Use correct C++ standard flag when building standalone testsAlexandru Croitor2020-02-181-0/+5
| | | | | | | | | | | | | | Before the patch we set the standard flags in two places: - once when building qtbase - and always when including QtSetup (for every repo that is built) This change makes sure to also set the correct standards flag when building standalone tests, because QtSetup is called to early in that case. Change-Id: Iad130b731e9eb9605bb91637364c33fdd49ce3cb Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devLiang Qi2020-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | Conflicts: examples/widgets/graphicsview/boxes/scene.h src/corelib/Qt5CoreMacros.cmake src/corelib/Qt6CoreMacros.cmake src/network/ssl/qsslsocket.cpp src/network/ssl/qsslsocket.h src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp src/testlib/CMakeLists.txt src/testlib/.prev_CMakeLists.txt tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp Disabled building manual tests with CMake for now, because qmake doesn't do it, and it confuses people. Done-With: Alexandru Croitor <alexandru.croitor@qt.io> Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io> Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-36/+13
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add custom targets for documentationLeander Beernaert2019-12-181-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Adds custom targets which take care of generating and installing documentation files. Every module has a global set of targets suffixed with the module name in order for them to be unique when we implement super builds. The targets are the same as the list below, but replace ${target} with the module's name. Eg.: docs_qtbase. For every target which has an qt_add_docs() call, we now create the following set of custom targets: * docs_${target} * html_docs_${target} * qch_docs_${target} * prepare_docs_${target} * generate_docs_${target} * install_docs_${target} * install_html_docs_${target} * install_qch_docs_${target} Fixes: QTBUG-75859 Change-Id: Ie84cb9a2dedbe7333d9a84f4d73383442deca477 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't include standalone tests config file if none existsAlexandru Croitor2019-11-131-1/+1
| | | | | | | | | | | Some repos like qtimageformats don't generate a config file for standalone tests because the repo creates no modules. Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Change-Id: Id42338804605a883f975feb5dd81eda5acc6e687 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Build test/manual if it contains a CMakeLists.txtLeander Beernaert2019-11-121-0/+3
| | | | | | | Change-Id: Ibada60b0902f9c6a6a7284489a56106e0021a9de Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 03:03:51 +0000