summaryrefslogtreecommitdiffstats
path: root/cmake/QtPostProcessHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix missing dependencies in *Depends headersJoerg Bornemann2020-11-191-1/+7
| | | | | | | | | | | | | | | In qt_internal_create_module_depends_file we're checking the target property INTERFACE_MODULE_HAS_HEADERS. However, this property is not exported, and in per-repo builds we do not have access to this. As we cannot export INTERFACE_* properties, we export another one, called _qt_module_has_headers. This amends commit 598e873c84e6544aa67495b9b9fb1ff22f98a293. Fixes: QTBUG-88503 Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix Core -> Core dependency in static buildJoerg Bornemann2020-11-121-1/+1
| | | | | | | | | | | | | | | Fix the overly strict regex in qt_internal_create_module_depends_file to allow for - and _ in module names. We had the above mentioned dependency cycle, because the module name Core_qobject was translated to just Core, creating a Core -> Core dependency. Amends da7609e7d0592b76ccb7cfb6c3136267172dc6bf. Fixes: QTBUG-88437 Change-Id: I866f7ce31e9a1b92fe4c0a6450295c2f3c761558 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cmake: Handle exported namespace when computing depsTor Arne Vestbø2020-11-111-2/+2
| | | | | | | We need to handle the possibility of versioned dep (Qt6::Foo). Change-Id: I66797dbc59f00500892958e9c99c4555cddcb980 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Handle genexes when computing dependsTor Arne Vestbø2020-11-111-1/+1
| | | | | | | If not, the resulting dep would end up as 'Foo>', but we need 'Foo'. Change-Id: I246b66eb0ac6b076eea200c4d1ad84bba8ed179c 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/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Don't add module header for interface libs without headersTor Arne Vestbø2020-10-281-0/+5
| | | | | Change-Id: Ifba869586a65f28d5ff47bb2c01ce638110f493f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Export QT_QPA_DEFAULT_PLATFORM in QtBuildInternalsExtraAlexandru Croitor2020-10-271-0/+8
| | | | | | | | | | | | The value is useful for QPA plugins built in repos other than qtbase, to decide if it should be a default plugin or not. Currently useful for qtwayland. Also export a qmake value assignment when doing static builds, just like src/gui/configure.pri does. Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Export 3rdparty dependency find_package calls of private modulesJoerg Bornemann2020-09-251-1/+12
| | | | | | | | | | | | | | | | Consider a Qt module with a 3rdparty library target in PRIVATE_MODULE_INTERFACE, e.g. XKB::XKB in Qt6::GuiPrivate. Consumers of GuiPrivate automatically depend on XKB::XKB. In order to do that they must find_package(XKB ...). As all find_package calls for GuiPrivate are in the same place as the ones for Gui, this package must be marked as optional. Otherwise all consumers of Qt6::Gui would have to have the xkbcommon package installed too. This patch exports find_package calls for every 3rdparty public dependency of private modules and marks them as optional. Change-Id: Ia1eeb09c29927fb6634ef08b477684ed6f123267 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "Revert "CMake: Add facility to mark package dependencies as optional""Joerg Bornemann2020-09-141-1/+2
| | | | | | | | | This reverts commit b0c51f86f40b6b6d18fe2bb75cc851d36395240d. The build failure caused by 58c1c6ee5c986d502b56eb1cc57f1d9444d42031 has been fixed. Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Add facility to mark package dependencies as optional"Lars Knoll2020-09-131-2/+1
| | | | | | | | | | This reverts commit 3685483c4b79b4075bab6d341174a395359d1b4a. This lead to configuration errors on some machines, blocking development. Change-Id: I309cdd55a8ef64899afcbeca54458d1c6d686951 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake: Add facility to mark package dependencies as optionalJoerg Bornemann2020-09-121-1/+2
| | | | | | | | | | | | | | | | Every public dependency of a Qt module results in a find_package call in the consuming project. But not all public dependencies are mandatory. For example, vulkan is only needed if the user project actually uses Qt classes that pull in vulkan headers. This patch adds the option MARK_OPTIONAL to qt_find_package. Dependencies that are marked as optional will not produce an error on find failure. Task-number: QTBUG-86421 Change-Id: Ia767e7f36991e236582c7509cbd37ea3487bb695 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Provide way to register extra tool package dependenciesAlexandru Croitor2020-09-111-1/+11
| | | | | | | | | | | | | | | This is needed for qtwayland, where QtWaylandCompositor package should call find_package(QtWaylandScanner) in the 'Tools' section of the ModuleDependencies.cmake file, rather than the regular 'Qt' section. This takes care of handling host path prefixes, to ensure that a host package is found even when tools have also been cross-compiled via the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING option. Task-number: QTBUG-83968 Change-Id: I4725a630214d053105fb6d2a0f7c5ff6128d13f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Handle -D, -I, -F and -L configure argumentsJoerg Bornemann2020-08-171-0/+16
| | | | | | | | | | | | | | Introduce new CMake variables and map -D to QT_EXTRA_DEFINES, -I to QT_EXTRA_INCLUDEPATHS, -L to QT_EXTRA_LIBDIRS, and -F to QT_EXTRA_FRAMEWORKPATHS. Those variables only affect the Qt build, not user projects. Fixes: QTBUG-85878 Change-Id: I229df2eed1505a2619068d0d32975962b052569a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmakeAlexandru Croitor2020-08-141-0/+644
The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>