path: root/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Bail out if the build dir is symlinkedJoerg Bornemann2020-12-211-0/+10
| | | | | | | | | | | | | | | | Building Qt in a symlinked build directory leads to all kind of issues, like unnecessary rebuilds, strange compilation errors or already errors at configure time. Detect this situation and bail out early with an informative error message. Task-number: QTBUG-88418 Task-number: QTBUG-89559 Change-Id: I70c16e11a7eede7a183f6f56b73ea93f985312f3 Reviewed-by: Cristian Adam <> Reviewed-by: Gatis Paeglis <> Reviewed-by: Liang Qi <>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 * 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: Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <>
* 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 <>
* CMake: Do not set PKG_CONFIG_* environment variablesJoerg Bornemann2020-11-121-10/+0
| | | | | | | | | | | | | This reverts commit 9968a211f92c2b4d5bd1fe004f16ec1c5f968dcd. The PKG_CONFIG_* environment variables should be added by the user environment, preferably by the toolchain file. Apparently, the change was added for Android before we turned off pkg-config for Android. It is not needed anymore. Change-Id: Ieeed09ae53a606c85d4937f463286b5b0f76bde9 Reviewed-by: Alexandru Croitor <>
* CMake: Bump the minimum required CMake version to build Qt to 3.18Alexandru Croitor2020-11-031-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <> Reviewed-by: Cristian Adam <>
* CMake: Fix building examples targeting iOS simulator with qmakeAlexandru Croitor2020-10-161-1/+2
| | | | | | | | | | | | | | | | | | | The makefile generated by qmake when building an iOS example tries to execute the mkspecs/features/uikit/ python script to find a simulator ID. When installing the mkspecs, we didn't preserve the source file permissions which means that the executable bit was stripped. This causes the makefile to call xcodebuild with an invalid simulator id due to not being able to execute the python script. Make sure to install the mkspecs directories preserving the source file permissions. Fixes: QTBUG-87639 Change-Id: Iaa33b740c93187155025891104e8a21c6e7c98c8 Reviewed-by: Cristian Adam <>
* CMake: Do not run auto-detection in top-level buildsJoerg Bornemann2020-10-121-3/+4
| | | | | | | | | | | The top-level CMakeLists.txt already does that to ensure that QtAutoDetect is included before any project command, meaning before any toolchain file is loaded. Task-number: QTBUG-87309 Change-Id: I60a998bdf999b6f751e4ebec2d13491fb206b132 Reviewed-by: Cristian Adam <> Reviewed-by: Alexandru Croitor <>
* CMake: Refactor optimization flag handling and add optimize_fullAlexandru Croitor2020-10-061-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* CMake: Disable usage of CMake API compatibility wrappersAlexandru Croitor2020-09-231-0/+3
| | | | | | | | | Setting the QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS variable in the project ensures we ported away from old API calls. Task-number: QTBUG-86815 Change-Id: I0d1868a24b0f4e0cc817c11fef160f8b392814af Reviewed-by: Joerg Bornemann <>
* CMake: Fix tst_moc to build when tests are built as part of Qt treeAlexandru Croitor2020-08-231-0/+1
| | | | | | | | | | | | | tst_moc uses qt_wrap_cpp, which tries to dispatch to qt6_wrap_cpp depending on the value of QT_DEFAULT_MAJOR_VERSION. That value is only set in, which is not loaded as part of the qtbase build unless something does find_package(Qt6Core). Set the QT_DEFAULT_MAJOR_VERSION to 6 before including the Qt6CoreMacros in the qtbase top-level project. Change-Id: I7b81d89d965f755e51727007e68771ac3931ac55 Reviewed-by: Joerg Bornemann <>
* CMake: Implement configure -optimize-debugJoerg Bornemann2020-08-201-0/+3
| | | | | | Task-number: QTBUG-85373 Change-Id: I3aba1fcf96e36544dd75a5e6adc5f770a9a45726 Reviewed-by: Alexandru Croitor <>
* CMake: Split out some Android functions into a public API fileAlexandru Croitor2020-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <>
* CMake: fix android target build not picking the correct sysrootAssam Boudjelthia2020-08-131-8/+8
| | | | | | | | | | This previous way caused target builds under Linux to pick the host packages like udev and mtdev and build for them which they will fail during the build. Task-number: QTBUG-86028 Change-Id: Ic029f0a3e71b50c694473a110922f0ef11e5b0bf Reviewed-by: Alexandru Croitor <>
* CMake: Protect against Qt toolchain file recursive inclusionAlexandru Croitor2020-06-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Three different people have encountered the issue that calling calling qt-cmake on a project prints 1000 inclusion lines of the same qt toolchain file, and then CMake bails out saying can't find the CMAKE_MAKE_PROGRAM Ninja. This happened because people accidentally called qt-cmake to configure qtbase (instead of just cmake), which created a toolchain file that chainloads itself recursively. Error out when configuring qtbase, and when using the generated toolchain file in the case when it would try to include itself. The solution is to remove the qtbase CMakeCache.txt file, and configure qtbase again, so it generates a proper qt.toolchain.cmake file. If somebody feels enthusiastic, they can move the check into the qt-cmake and qt-cmake-private shell scripts, and error out before the qtbase/CMakeCache.txt is polluted with the wrong toolchain file. That is left for people that feel more comfortable with bash and batch scripting. Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64 Reviewed-by: Joerg Bornemann <>
* Generate .cmake.conf files for versioningMårten Nordheim2020-04-301-1/+2
| | | | | | | | And create one for QtBase at the same time. Fixes: QTBUG-83835 Change-Id: Icc6b022165a57bd4e22c23bdb0016522b99a5b80 Reviewed-by: Alexandru Croitor <>
* CMake: Fix pkgconfig calls when cross-compilingLeander Beernaert2020-03-261-0/+10
| | | | | | | | | | | | | | When cross-compiling with CMake, before this patch pkgconfig calls would find libraries which are part of the host system and not the target system. The current approach used is based of the discussion present in, and should be considered a temporary solution until the issue is properly addressed in upstream CMake. Change-Id: I535d4d48c2a5d34689082b80501b3b6ae30d7845 Reviewed-by: Alexandru Croitor <>
* CMake: Fix auto-detection of precompiled header supportAlexandru Croitor2020-03-251-3/+0
| | | | | | | | | | | | PCH files were only used while building qtbase. Make sure the value is exported to the BuildInternalsConfig file, so the value is re-used when building other repositories. Also disable PCH when building simulator_and_device iOS builds, because CMake doesn't currently generate separate PCH files per architecture. Change-Id: I79955ebc557b800bc3c704deac519fe80012c229 Reviewed-by: Simon Hausmann <>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-1/+1
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <>
* cmake: Fix naming when referring to Apple macOSTor Arne Vestbø2020-03-161-1/+1
| | | | | Change-Id: Iafb5e448d0d65d42f788464fc600594a5666f9af Reviewed-by: Alexandru Croitor <>
* cmake: Add default Info.plist for macOS with some important keysTor Arne Vestbø2020-03-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <>
* CMake: Fix mkspec install commandsLeander Beernaert2020-03-111-3/+8
| | | | | | | | If there is a file present in the globbed mkspecs_subdirs file list we run into an invalid argument error for the install(DIRECTORY) command. Change-Id: I0fe61a8f0a863854f55cf62a87417bcaec1d2c29 Reviewed-by: Alexandru Croitor <>
* Regenerate rest of qtbaseAlexandru Croitor2020-02-041-0/+1
| | | | | | Change-Id: I3a1ce255d26522d8ad6694c5b0daaa53fb694de3 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <>
* Add INSTALL_MKSPECSDIR to the install locationsChristophe Giboudeaux2020-01-311-3/+8
| | | | | | | | | | | | | Linux distributions may want to install mkspecs files into a different subdir in order to make Qt6 co-installable with older versions. Contributes to QTBUG-81289 Change-Id: Ie4a64370d742948d5ca4f2eaed6ea550d2676707 Reviewed-by: Qt CMake Build Bot Reviewed-by: Christophe Giboudeaux <> Reviewed-by: Alexandru Croitor <>
* Add custom targets for documentationLeander Beernaert2019-12-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* Collect Json Metatypes from CMake's AutomocLeander Beernaert2019-12-041-0/+3
| | | | | | | | | | | | | | | | | | | | This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <>
* 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 <>
* Make standalone tests build via top level repo projectAlexandru Croitor2019-11-081-45/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 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/ projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <>
* Fix usage of BUILD_SHARED_LIBS in configure.cmakeJoerg Bornemann2019-11-071-10/+10
| | | | | | | | | | | Feature conditions that used BUILD_SHARED_LIBS evaluated to false, e.g. FEATURE_framework. The options must be declared before the configuration files are included. Change-Id: I1ccda8234b334371d22e19f7f6d4fba3a1e7b857 Reviewed-by: Leander Beernaert <> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <>
* Pick the latest available C/C++ standard when compiling QtSimon Hausmann2019-10-171-0/+2
| | | | | | | | | | This maps the behavior of mkspecs/features/qt_common.prf and enables the use of C++17 for example in Android, where the toolchain supports it anyway. Change-Id: I41f4bdb160a3929e2fb78f36efb1ad5f2ad391a5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Mårten Nordheim <>
* Include QtPlatformSupport as part of find_package(Qt6BuildInternals)Alexandru Croitor2019-09-271-2/+3
| | | | | | | | | | | This is needed because the ported over requires() clauses from qmake to CMake are executed before qt_repo_build(), which means that all the custom platform variables that we set (like LINUX, APPLE_OSX) need to be available immediately after finding BuildInternals. Change-Id: I7345b69edf72c266508846766e64f42c99862d1d Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <>
* Create module tools packages (config files) automaticallyAlexandru Croitor2019-09-221-3/+0
| | | | | | | | | | | | | | | | | | | | | Previously you had to make sure to use DISABLE_TOOLS_EXPORT in an add_qt_module call if the tools are built after the module, as well as to manually call qt_export_tools after all associated tools are built. This was needlessly complex, especially for people that are porting a repo with tools for the first time. The tools package creation is now automatically done at QtPostProcess step, so there is no need to use either DISABLE_TOOLS_EXPORT or qt_export_tools() manually. DISABLE_TOOLS_EXPORT is now a no-op, and will be removed once all repos are updated not to use it. Change-Id: I965b0d3a8a0cb908afae87b047083ed7bea9f02f Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <>
* Use pre-compiled headers when building Qt with cmakeMårten Nordheim2019-09-111-0/+3
| | | | | | | | | | | | | | | | | | Some modules define their own manually-maintained lists, and we can rely on the headers generated by each module to include in the pch as well e.g. QtCore/QtCore. There's also e.g. QtWidgetDepends for QtWidgets, but this only works for modules, not for tools, examples or other applications. For now we'll use the Qt<Module>/Qt<Module> headers for the modules we depend on. Building with PCH can be disabled with -DBUILD_WITH_PCH=NO, and it only works for versions of CMake newer than 3.15.20190829. Change-Id: Iae52bd69acfdfd58f4cd20d3cfa3c7f42775f732 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <>
* Propagate BUILD_TESTING and BUILD_EXAMPLESAlexandru Croitor2019-09-061-2/+1
| | | | | | | | | | | | | | 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 <> Reviewed-by: Qt CMake Build Bot
* Fix exporting of Core toolsAlexandru Croitor2019-07-241-0/+3
| | | | | | | | | | | | | | | It should happen after qmake is built, to make sure that the target is made global, otherwise when cross-building qtbase in another build tree, the configuration phase will fail due to not finding qmake. qmake was accidentally exported before if you configured qtbase twice, because the tool was kept around in a cache variable, the second configuration actually recreated the CoreToolsConfig.cmake file to contain qmake as well. Change-Id: I6941e83f7d6bd03c56de120fba1d18e50c4af0e4 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <>
* Add auto detection routines for androidLeander Beernaert2019-06-271-19/+2
| | | | | | | | | | Add QtAutoDectect cmake which has routines to handle the vcpkg detection as well as set up some android configuration parameters. The latter will contribute towards keeping the cmake configuration commands shorter when targeting android. Change-Id: I721291c8dce39b5c298565a46867ddcab2df90e8 Reviewed-by: Simon Hausmann <>
* Fix build of modules outside of QtBase when cross-compilingSimon Hausmann2019-06-241-0/+9
| | | | | | | | | The Qt::Platform target includes the mkspecs/$spec directory, which we must unconditionally install as long as we use it. Change-Id: I272650a887b5b0b3bd868524784dca65b76b02d9 Reviewed-by: Alexandru Croitor <> Reviewed-by: Qt CMake Build Bot
* Add support for picking up vcpkg automaticallySimon Hausmann2019-06-201-2/+18
| | | | | | | | | | If VCPKG_ROOT is defined, let's use it and chainload any previously set toolchain file. The detection of vcpkg support via the VCPKG_ROOT environment variable is per vcpkg documentation, the automatic chainloading is something specific to us. Change-Id: I0498effc5b948f0b6f5e223d0454a15a0cbb503a Reviewed-by: Alexandru Croitor <>
* Add support for vcpkg default target tripletsSimon Hausmann2019-06-201-0/+4
| | | | | | | | | | | | | As per vcpkg documentation, this is a tweak that allows respecting the vcpkg default target triplet environment variable, which simplifies the command line slightly. In order to make this also work for modules other than qtbase, we're going to need to consider the creation of a toolchain file. Change-Id: I2573f6644d671c710fd823df83e2205dbbfe19e6 Reviewed-by: Alexandru Croitor <> Reviewed-by: Qt CMake Build Bot
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-1/+1
| | | | | | | | | | This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
* Fix linking of examplesSimon Hausmann2019-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <> Reviewed-by: Alexandru Croitor <>
* Prevent accidental conflicts with external cmake configuration filesSimon Hausmann2019-06-061-2/+2
| | | | | | | | | Make sure to prepend our own paths instead of appending, as we'd like cmake to search there first. Change-Id: I0caea3a2654fbb07d5843f255cc35fca8892e19d Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <>
* cmake: Add warnings_are_errors optionAlbert Astals Cid2019-06-051-0/+3
| | | | | | | | | | | | | for modules, plugins and tools only (i.e. no tests nor examples) this mimics the qmake behavior default value is developer_build Comes with some fixes in qmake since it seems in the qmake built it was not having Werror, now does because we built it with add_qt_tool Change-Id: I6f3237f25a6fedefa958644929e90f13837a12df Reviewed-by: Alexandru Croitor <>
* Fix static usage requirements for XcbQpaJean-Michaël Celerier2019-06-051-1/+1
| | | | | | | | | | | | | In particular, Qt targets extended with other qt targets (eg. Qt::VulkanSupport or Qt::LinuxAccessibilitySupport) after the first add_qt_module were not taken into account when generating Depends files. Note that this patch updates the minimum required version to CMake 3.15 Change-Id: I747deedd4d59e385876bc1a834ef9bdb6078911b Reviewed-by: Alexandru Croitor <>
* Fix build against sysrootsSimon Hausmann2019-05-291-1/+1
| | | | | | | | | | | Toolchain files from sysroots (such as Yocto or Android) typically set the CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY to ensure that no external packages are accidentally found. Similar to how we discover the Qt tools packages for cross-compiling, we need to temporarily change the mode to BOTH to locate our build internals. Change-Id: Ib4374ee4a974379213218b7ec430637857ed02e7 Reviewed-by: Alexandru Croitor <>
* Use the qt_build_repo() macros for building qtbase as wellAlexandru Croitor2019-05-151-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <>
* Update version in cmake to 5.14.0Liang Qi2019-05-021-1/+1
| | | | | | | The dev->wip/cmake merge is done already. Change-Id: Ia6b17ac633cd2bcd1e9f6e96a0a0bf33042ed63b Reviewed-by: Alexandru Croitor <>
* Export tool config and target files for each relevant moduleAlexandru Croitor2019-05-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <>
* Force feature_summary to fail when a required package is not foundAlexandru Croitor2019-04-081-1/+6
| | | | | | | | | | | | | | | | | | Apparently calling set_package_properties with TYPE REQUIRED and then calling feature_summary with FATAL_ON_MISSING_REQUIRED_PACKAGES and PACKAGES_NOT_FOUND is not enough to make CMake fail when not finding a required package. You have to explicitly set REQUIRED_PACKAGES_NOT_FOUND to force feature_summary to fail when a package is not found. Do this, and also explicitly add the rest of the NOT FOUND cases, to get a slightly clearer overview what kind of packages were not found. Task-number: QTBUG-74133 Change-Id: Id21af13dafafe0a458cff479e8abbc6aa7e6a3f7 Reviewed-by: Tobias Hunger <>
* Skip the qmake build when cross-compilingSimon Hausmann2019-02-181-1/+3
| | | | | Change-Id: I24da7eb9587235aa937a984e91a833284b4f28e5 Reviewed-by: Kevin Funk <>
* Fix build of neon accelerated drawing helpersSimon Hausmann2019-02-111-1/+1
| | | | | | | | We must instruct cmake that we're interested in providing input files for the assembler directly and the file name needs to be correct, too :) Change-Id: I7cccb6ac66d28261ee71869991b14ac20c63050e Reviewed-by: Liang Qi <>