summaryrefslogtreecommitdiffstats
path: root/cmake/QtBaseGlobalTargets.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-14/+43
| | | | | | | | | | | | | | | | | | | | | | | QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce QtFeatureCommon.cmakeJoerg Bornemann2020-08-131-0/+1
| | | | | | | | This file provides common feature-functionality is supposed to be included by QtFeature.cmake and QtProcessConfigureArgs.cmake. Change-Id: Ifb483c2a9c4014d240c2a4d6ff07b5c0ceee9c3a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix build with custom INSTALL_INCLUDEDIRJoerg Bornemann2020-08-061-5/+5
| | | | | | | | | | | | | The include directory in Qt's build directory is always named "include", no matter what the value of INSTALL_INCLUDEDIR is. The main reason is that the name "include" is hard-coded in syncqt. The INSTALL_INCLUDEDIR variable must only affect the installation location of headers. Fixes: QTBUG-85893 Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated content of prl files (again)Alexandru Croitor2020-07-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Introduce qt_internal_add_appAlexandru Croitor2020-07-311-0/+2
| | | | | | | | | | | | | | | This new function is meant to be used where load(qt_app) is used. It delegates functionality to qt_add_executable, while handling some additional behavior via a finalization function (mostly handling of macOS Info.plist files and icons, as well as Windows icons and resource files) It uses a new PlatformAppInternal interface target. Task-number: QTBUG-85757 Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATHAlexandru Croitor2020-07-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to implement the 'host artifact reuse' Coin instructions change, a bug surfaced where the qemu configurations didn't find the host tools and instead tried to use the cross-compiled tools while building qtbase, which failed due to not finding the runtime linker (another unsolved issue). Before the host artifact reuse change, the host tools were found successfully. The difference that caused the issue is that the target install prefix was a direct subfolder of the host prefix. host - /home/qt/work/qt/install target - /home/qt/work/qt/install/target Before the host reuse change the install prefixes were as follows host - /home/qt/work/qt/install/host target - /home/qt/work/qt/install/target While looking for the Qt6CoreTools package, we temporarily set CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first '/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'. CMake then reroots the CMAKE_PREFIX_PATH values onto values in CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search. Rerooting essentially means concatenating 2 paths, unless the considered prefix is a subfolder of the root path. What happened was that the first considered value was '/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent location that gets discarded. The second considered value was '/home/qt/work/qt/install/target. The second value is the result of seeing that '/home/qt/work/qt/install/target' is a subfolder of '/home/qt/work/qt/install' and thus the root path is stripped. All of this is done in cmFindPackageCommand::FindConfig() -> cmFindCommon::RerootPaths. The behavior above caused the target tools be found instead of the host ones. Before the host reuse change, both of the initial constructed prefixes were discared due to them not existing, e.g. '/home/qt/work/qt/install/target/home/qt/work/qt/install/target' and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host' One of the later prefixes combined CMAKE_FIND_ROOT_PATH == '/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting in '/home/qt/work/qt/install/host/' and this accidentally found the host tools package. We actually stumbled upon this issue a while ago when implementing Qt 5.14 Android CMake support in 52c799ed4425076df4353c02950ea1444fe5f102 That commit message mentions the fix is to add a "lib/cmake" suffix to the PATHS option of find_package(). This would cause the subfolder => strip root behavior mentioned above. So finally the fix. First, make sure not to append QT_HOST_PATH in the toolchain file, there shouldn't be any need to do that, give that we temporarily set it when looking for Tools packages. Second, recreate the subdir scenario in the Qt toolchain file by setting CMAKE_FIND_ROOT_PATH to the current (relocated) install prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value poining to the CMake directory. Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'. Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host equivalents of the target ones above. Use these values when looking for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing the subdir behavior. Note these are currently absolute paths and are not relocatable. We'll have to figure out if it's even possible to make the host path relocatable. Finally as a cleanup, look for the Qt6HostInfo package in QtSetup strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find a system Qt package. Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add OS-specific prelude to qt-cmake-standalone-testJonas Karlsson2020-07-151-0/+2
| | | | | | | | | | | | This makes sure the executable is run as a shell script with the proper interpreter on Unix systems. Otherwise it will fail in some shells, like fish. On windows, it prevents all commands in the batch file from displaying on the screen. Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix qt-cmake-standalone-test when CMAKE_STAGING_PREFIX is setJoerg Bornemann2020-07-091-3/+3
| | | | | | | | | | The qt-cmake-standalone-test script is kind of a "host tool" and contained paths to CMAKE_INSTALL_PREFIX, which is wrong if CMAKE_STAGING_PREFIX points to somewhere else. Fixes: QTBUG-85336 Change-Id: I4828dc6868d55cfc60f3ad2199185230d5cc9028 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate qdevice.pri when cross-buildingJoerg Bornemann2020-06-291-0/+1
| | | | | | | | | | | | | This adds the CMake equivalent to the classical -device-option key=value configure argument: -DQT_QMAKE_DEVICE_OPTIONS=key1=value1[;keyN=valueN] The keys and values get dumped verbatim into qdevice.pri. This patch also ports the machineTuple configure test. Its result is written into qdevice.pri as value for the GCC_MACHINE_DUMP variable. Change-Id: I29f2323fd87639fafaed99ec7446c7ee75504705 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Support cross-compilation with qmakeJoerg Bornemann2020-06-291-0/+1
| | | | | | | | | | | | | When cross-compiling, we now create a target_qt.conf file that's to be used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf" projects can be cross-built against the cross-built Qt. We also create wrapper scripts for the host qmake to save the user from passing the -qtconf argument. Fixes: QTBUG-82581 Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Improve automatic compiler embedding into the Qt toolchainAlexandru Croitor2020-06-181-4/+42
| | | | | | | | | | | | | | | | | Embedding the initial CMAKE_CXX_COMPILER into qt.toolchain.cmake breaks Boot2Qt builds, because the CXX environment variable is not used anymore when building qtsvg or other projects. Disable automatic embedding when cross-compiling, while keeping it enabled for non-cross-compiling cases (to keep Windows and and ICC configurations working). Allow opting in or out of the embedding in case if the default is wrong, via QT_EMBED_TOOLCHAIN_COMPILER. Task-number: QTBUG-85067 Change-Id: I1d8f9f580bc379b77c34eefb5728bb49f93cc81a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Do not generate qtbase/bin/qt.confJoerg Bornemann2020-06-111-1/+0
| | | | | | | | | | | | | | | | | | In a qmake build this file serves the purpose of setting the right prefixes for the build directory's qmake binary. This can be used to build Qt repositories other than qtbase, esp. in a top-level build. In the CMake build, we don't have qmake top-level builds, and we do not support building Qt repositories with the build directory's qmake binary (exception: non-prefix build). To build a Qt module or user project with qmake, the installed qmake must be used. This fixes qmake for non-prefix top-level CMake builds. Change-Id: Ibd10c36e8359225553d782d0c8117760db9f3370 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix libraries in qt_lib_XXX_private.pri files for NMCJoerg Bornemann2020-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | qmake_use.prf understands the _DEBUG and _RELEASE suffixes for QMAKE_LIBS_XXX entries. The CMake configuration "Debug" is considered for the _DEBUG entries, "Release" and "RelWithDebInfo" for _RELEASE. The qt_lib_XXX_private.pri files are now generated in multiple steps: 1. The QT_LIBS_XXX information is generated per $<CONFIG> and written to .cmake files. 2. A preliminary qt_lib_XXX_private.pri file is generated, containing only configuration-independent data. 3. A custom command runs the QtGenerateLibPri.cmake script that combines the files from step 1 and 2 into the final qt_lib_XXX_private.pri file. The same is done for mkspecs/qmodule.pri. To be able to trigger custom commands from header modules, which are interface libraries, we introduce one XXX_timestamp ALL target per header module that creates a timestamp file. To that XXX_timestamp target we add the pri file generation target as dependency. Fixes: QTBUG-84348 Change-Id: I610f279e37feeb7eceb9ef20b3ddfecff8cfbf81 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Do not create Qt6ToolsConfig[Version].cmake filesJoerg Bornemann2020-06-081-19/+0
| | | | | | | | They are not necessary, and they conflict with what qttools generates. Fixes: QTBUG-82133 Change-Id: I4a1273d694626345b32b45c653dd31d3b78621eb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Protect against Qt toolchain file recursive inclusionAlexandru Croitor2020-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <joerg.bornemann@qt.io>
* CMake: Fix standalone tests to work properly on reconfigurationAlexandru Croitor2020-06-041-0/+8
| | | | | | | | | | | | | | | | | 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: Generate information about 3rdparty libs in module .pri filesJoerg Bornemann2020-05-191-0/+1
| | | | | | | | | | | | | For modules that are not yet ported to CMake and that use QMAKE_USE += libfoo we need to provide the information about libfoo in the qt_lib_XXX.pri files. Also, we now generate qt_ext_XXX.pri files for bundled 3rdparty libs. Task-number: QTBUG-75666 Change-Id: I9e4b057a197554ecb37c294c0bf09e2a2b3aa053 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Use custom install script to support Ninja Multi-Config buildsAlexandru Croitor2020-05-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Calling cmake --install . only installs a single configuration. To install both debug and release artifacts, the install invocation needs to be done for each configuration. To keep the Coin instruction code simpler, delegate the looping over configurations to a custom CMake script, and use it in the Coin instructions. Replace all cmake --install calls in the instructions with calls to either call_host_install.yaml or call_target_install.yaml. The path to the script depends on whether we are building qtbase or another module. In the former case the script should be called from the build dir, otherwise from the install dir. The other distinction is whether the host or target env prefix needs to be added. Task-number: QTBUG-80900 Change-Id: Ied4bf739e2b1a2307f22fc79c1cfad746c8cbc44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable default usage of utf8 sources for Qt consumersAlexandru Croitor2020-05-151-0/+3
| | | | | | | | | | And enable the same default when building Qt itself (it's implicit). Allow opting out on a target-by-target basis, by using the public qt_disable_utf8_sources() API call. Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Replace hardcoded include dirs for the global qtbase targetsAlexandru Croitor2020-05-071-8/+8
| | | | | | Change-Id: I22a120a0cb8ca690d224b1301b85e704364fbce0 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Move Resources API into Qt6CoreMacrosLeander Beernaert2020-04-201-10/+0
| | | | | | | | Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate qmake pri information for building with qmakeAlexandru Croitor2020-04-171-0/+2
| | | | | | | | | Implemented some necessary functionality to generate correct .pri information, so that qmake can build modules. Task-number: QTBUG-75666 Change-Id: I63281adfef3d01385928b1d8c4be0b32ac97c4d7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate qmake .prl filesJoerg Bornemann2020-04-171-0/+1
| | | | | | | | This commit also adds a qt_finalize_module function that is called for every Qt module after all link dependencies have been added. Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make sure to install Qt3rdPartyLibraryConfig.cmake.inAlexandru Croitor2020-03-231-0/+1
| | | | | | | | | | Repos like qtshadertools need it when configuring their own bundled libraries. Amends 572c03eb7a583baf1f48e5144d2868e5588d292a Change-Id: I540e99d5bd2938299a10220a1a5e0d97091077b3 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Introduce qt_configure_fileAlexandru Croitor2020-03-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It has the same kind of signature as file(GENERATE) but creates the files at configure time rather than generation time. CMake provides a few ways to generate files file(WRITE) -> always overrides content configure_file() -> only overrides if content changes, creates file at configure time, can only take a file as input file(GENERATE) -> only overrides if content changes, creats file at generation time, can take a string or file as input Because dealing with an input file is a hassle (need to create one, make sure it's installed, make sure it's used correctly in the various build types like super-build, non-prefix-build, etc) people tend to use file(GENERATE) instead, which can take a string argument, and is thus easier to use. Unfortunately that introduces subtle bugs because the file is created at generation time, but there are existence checks which are done at configuration time. Thus qt_configure_file allows creation of files at configure time, without having to provide an input file. Underneath it uses configure_file(). Once CMake 3.18 is released, the implementation can be switched to use file(CONFIGURE). Change-Id: Ic8f8d88541ef0b25d01af143352c8c9ba390ad5f Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Provide script to configure and build one or more testsAlexandru Croitor2020-03-231-23/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-4/+4
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Fix naming when referring to Apple macOSTor Arne Vestbø2020-03-161-1/+1
| | | | | Change-Id: Iafb5e448d0d65d42f788464fc600594a5666f9af Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Add default Info.plist for macOS with some important keysTor Arne Vestbø2020-03-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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 <alexandru.croitor@qt.io>
* CMake: Install the QtBuildInternalsAndroid.cmake filleAlexandru Croitor2020-03-121-1/+5
| | | | | | | | | | It's needed when building qtdeclarative. Needs to be copy_or_install to support non-prefix builds as well. Change-Id: Ied59f6a1f8403be3721a0ad46f5a3b2f569028ca Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Propagate minimum required C++ standard to consumers of QtAlexandru Croitor2020-03-121-0/+4
| | | | | | | | | Aka the version of C++ that needs to be supported when compiling applications that use Qt headers (C++17 at the moment). Change-Id: I64dec297e8329f31b1d9864f216a95782049ed06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Port the 'separate_debug_info' featureJoerg Bornemann2020-03-061-0/+2
| | | | | | | | | | | | | | | For this, we have to uninline the separate_debug_info configure test, because supporting the conversion of this in configurejson2cmake is not worth the hassle. Separate debug information can be turned on for a target by calling the function qt_enable_separate_debug_info. For Qt's shared libraries and tools separate debug information is generated if the 'separate_debug_info' feature is manually turned on. Change-Id: Ic2ffc15efef3794dc0aa42f3d853ef6d651a751c Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle conditions in third party find modules correctlyAlexandru Croitor2020-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | Previously the FindWrap modules checked for hardcoded features when deciding whether to use a bundled library or not. This proved not to work correctly because features were not available when the find modules were processed. Introduce a new CMake API call that needs to be manually called after an add_subdirectory call which declares a bundled library. The call will check for the existence of the bundled target, and will then set a cache variable QT_USE_BUNDLED_Bundled<TargetName>. The same variable is written into a FindWrapFooConfigExtra.cmake file which will be loaded by the appropriate FindWrap module. The module can that use that variable to decided whether to link against the bundled library or the system library. Change-Id: I75e9a4f4e14d88d4490916a79ad12f1ce57891e0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Allow building bundled 3rd party libraries in qtbaseAlexandru Croitor2020-02-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* CMake: Fix c++ standard config tests with MSVCAlexandru Croitor2020-02-181-0/+2
| | | | | | | | | | | | Need to pass additional -Zc:__cplusplus flag when using MSVC, so that the __cplusplus define has correct values. Additionally make the option be propagated to consumers of Qt via the public Platform target, which QtCore links against. Change-Id: Ie1283c25334b93f993529beb7fb32bdb001627f5 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Don't hardcode the include directory nameChristophe Giboudeaux2020-01-311-1/+1
| | | | | | | | | | | | Hardcoding "lib" caused build issues and wrong INTERFACE_INCLUDE_DIRECTORIES paths in generated CMake configuration files if INSTALL_INCLUDEDIR pointed to a different location. Contributes to QTBUG-81289 Change-Id: I3276ecbb4bf5df1c0b4c496c0287b4a69586d683 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't hardcode the binary directory nameChristophe Giboudeaux2020-01-311-4/+4
| | | | | | | | | | | INSTALL_BINDIR may point to a different location than "bin". In order to avoid errors when trying to install qtbase, "bin" is replaced with "INSTALL_BINDIR" where necessary. Contributes to QTBUG-81289 Change-Id: I1d4f9fb2617547c9b0e44d6690caebb2b6768e2f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add INSTALL_MKSPECSDIR to the install locationsChristophe Giboudeaux2020-01-311-2/+2
| | | | | | | | | | | | | 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 <christophe@krop.fr> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix CMAKE_BUILD_TYPE to be a cache variable in QtBuildInternalsExtraAlexandru Croitor2020-01-291-7/+1
| | | | | | | | | | Rather than pass the build type in the wrapper, make sure the build type is a cache var, so it gets picked up when building other repos. This reverts commit f72ca4cf853619efb99ab08da803536392229d37. Change-Id: I5d91ab66249b6c40c5e548b0eec0e467ba0f2ebc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Forward CMAKE_BUILD_TYPE, if available, in qt-cmakeLeander Beernaert2020-01-291-1/+7
| | | | | Change-Id: I299e16cfc084b3fc009e806902e26121ebdd454b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-6/+2
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Make sure to install QtModuleToolsVersionlessTargets.cmake.inAlexandru Croitor2019-12-061-0/+1
| | | | | | | | | | | | Amends 04d895681adab24829be44c392534bcbe9d6c106 Task-number: QTBUG-74137 Task-number: QTBUG-80477 Task-number: QTBUG-75984 Change-Id: I617c2abf421bc1378545e5a36fd44533131ef471 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add initial support for cross-building to iOSAlexandru Croitor2019-12-031-2/+29
| | | | | | | | | | | | | | | | | | | | | | Tested locally with the following configurations: - iOS device builds (arm64) - iOS simulator builds (x86_64) - iOS simulator_and_device builds (fat arm64 and x86_64 archives) All iOS builds currently require a custom vcpkg fork which contains fixes for building the required 3rd party libraries. qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2 have also been tested to build successfully. simulator_and_device builds are also supported, but require an umerged patch in upstream CMake as well as further patches to vcpkg. Task-number: QTBUG-75576 Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Make sure to install QtStandaloneTestsConfig.cmake.inAlexandru Croitor2019-11-121-0/+1
| | | | | | | | | Otherwise leaf modules fail to configure. Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Change-Id: Ie304c0021ada9911044abdb7e460b8da8e986a8f Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Write out a module description fileTobias Hunger2019-10-211-0/+1
| | | | | | | | | Write out a file with some JSON data to describe a module. This file contains information on how that module has been built. Change-Id: I8a604692663cbb7b76b96b97124130e30b822e4b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Prospective fix for linking problems of qtdeclarative in the CISimon Hausmann2019-09-031-5/+5
| | | | | | | | | | | In the ICC configuration we can't build the qtbase libraries with ICC and qtdeclarative with gcc, mixing won't work well. On Windows we've covered this compiler mixing scenario using our toolchain file, but the ICC case makes it clear that we have to be consistent about caching the compiler in the toolchain file across platforms. Change-Id: Iad2005ab00655f902e5f5cea2f0563d790d8aa93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Extract add_qt_resource into reusable componentsLeander Beernaert2019-08-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 00:18:12 +0000