summaryrefslogtreecommitdiffstats
path: root/cmake/QtBaseGlobalTargets.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Fix Android build for other Qt modulesLeander Beernaert2019-08-161-0/+4
| | | | | | | Install missing QtBuildInternalsAndroid to installation path. Change-Id: I6141ff72b57a6445f1718bc17d64a7ed59a91620 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Install QtPlugins.cmake.inLeander Beernaert2019-08-121-0/+1
| | | | | | | Added rule to install missing QtPlugins.cmake.in. Change-Id: I485dadd56ee2dd435406d97399b32dc6390cebff Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix toolchain path when doing non-prefix buildsAlexandru Croitor2019-07-031-0/+7
| | | | | | | | | | | Previously the cmake install prefix was added twice during a non-prefix build, which evaluated to an incorrect path. Set another absolute dir variable, and use that instead. Change-Id: I73099510dadc8f401d5a763f21840c9671686c10 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Add auto detection routines for androidLeander Beernaert2019-06-271-0/+4
| | | | | | | | | | 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 <simon.hausmann@qt.io>
* Prospective fix for using qt-cmake when %PATH% changes and using NinjaSimon Hausmann2019-06-261-0/+5
| | | | | | | | | Mixing compilers won't work well on Windows, so if qtbase is built using cl.exe and Ninja and then later cmake is called on another module and gcc is found in %PATH%, then cmake will prefer that. Let's avoid that. Change-Id: I8294482939efa6a16e0a4df8df3aeef8243c3657 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix osx deployment target and sysroot propagation in the qt toolchainSimon Hausmann2019-06-261-0/+10
| | | | | | | | | We need to save them in the toolchain file, otherwise we can't compile anything :) Change-Id: Ic5c53524fa4aa05d0b3229c2905dff92ca437ec1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* Add windows batch file for convenient cmake invocation with Qt toolchain fileSimon Hausmann2019-06-251-0/+3
| | | | | | | | | Similar to the shell script, this makes it easier to invoke cmake by just extending your PATH. Change-Id: I1f83e93c507032f6ecf4838c11d62f49f4d93ed6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix vcpkg default target triplet setting in the qt toolchain fileSimon Hausmann2019-06-241-1/+1
| | | | | | | Due to scoping this variable needs to be written into the cache. Change-Id: I2704fe9ac138210571e0b7acada5eb5c65e265af Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Generate a toolchain and convenience cmake wrapperSimon Hausmann2019-06-241-0/+28
| | | | | | | | | | | | | | | | | This gets us a step into the direction of convenience that qmake offered: * QtBase is configured with a long command line (especially when cross-compiling) * Afterwards application developers (or other module builds) can just use qmake && make By generating a toolchain file we can capture vcpkg and toolchain chain-loading and a shell script can take care of providing the prefix path. Change-Id: Ided81f5432cab862306f2bea86cfe8e56adf71b0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add PlatformCommonInternal target and QT_NO_DEBUG definitionAlexandru Croitor2019-06-241-2/+8
| | | | | | | | | | | | | | All the other PlatformModuleInternal, PlatformPluginInternal, PlatformToolInternal target will depend on the common one. Also add the QT_NO_DEBUG definition when the build type is not Debug. This fixes the lookup of the Qt platform plugin on macOS, which uses a "_debug" prefix in the plugin name depending on if the QT_NO_DEBUG definition is present or not. This is the same as it is done in mkspecs/features/qt.prf. Change-Id: I82cf461d44b8a3b3c5dc2b2d9f25baa246fc1e4b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-2/+2
| | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 02:00:48 +0000