summaryrefslogtreecommitdiffstats
path: root/cmake/QtPostProcess.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmakeAlexandru Croitor2020-08-141-641/+2
| | | | | | | | | | | The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix Threads::Threads dependency handling with CMake < 3.18Alexandru Croitor2020-08-121-0/+2
| | | | | | | | | | | | | | | | | | | | Apparently CMake encods targets from different scopes with a different encoding scheme for earlier CMake versions. CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50> CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@ Handle the earlier version approach as well. It needs to be done both when writing out 3rd party dependencies, as well as for lib prl files. Possibly in more places as well, but I didn't detect additional places yet. Amends 92ee9bd6b885879090ba57e49c8bd84a06d42b2b Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Prepare ground work for static Qml plugins importingAlexandru Croitor2020-08-121-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | 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: Provide old style CMake variables for target infoAlexandru Croitor2020-07-171-0/+5
| | | | | | | | | | | | | | | | | | | | | This change provides the following per-module variables Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS, Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS. These are deprecated and are only intended for easier porting from Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets e.g target_link_libraries(app PRIVATE Qt6::Widgets) Note that the variable contents includes transitive values for everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS will contain values for Widgets, Gui and Core. Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when that is used in target_link_libraries(), CMake will take care of the transitivity. Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix old style find_package(Qt6Foo) to workAlexandru Croitor2020-07-171-1/+7
| | | | | | | | | | Each module package needs to first find the Qt6 package to ensure that all the necessary info is setup for further depedencies to be found. Task-number: QTBUG-81672 Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix QT_STAGING_PREFIX for repos other than qtbaseJoerg Bornemann2020-07-131-0/+12
| | | | | | | | | | | | | For repositories other than qtbase the QT_STAGING_PREFIX was empty, because it was only determined in qtbase. Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package and set this variable if it's not explicitly set by the user. As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON. Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Adjust some status messages about syncqt and file generationAlexandru Croitor2020-06-301-3/+0
| | | | | | | | | | | Show a status message when we run syncqt for a module (gives a bit more insight into why the configuration seems to stall for a moment). Remove some uninformative messages about generating config.h files and Depends headers, etc. Change-Id: I5ff2774b9cf5d92ddde564dc09f4197c2835ee4a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't use libraries in /usr/local by default on macOSAlexandru Croitor2020-06-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Create Qt6HostInfo packageJoerg Bornemann2020-06-281-0/+16
| | | | | | | | | | | | This package is supposed to be loaded when cross-building Qt from the host Qt installation prefix. It provides information about the host Qt by setting various variables. The information reflects what "qmake -query" of the host Qt would return. All provided variable names begin with "QT6_HOST_INFO_". Change-Id: Id568923a318d6e3b48c450663519a3727f615a8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Match tense of other log outputTor Arne Vestbø2020-06-261-1/+1
| | | | | Change-Id: Ied164c97bd54f6b37450d7a2cf8225ee5190ce17 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Improve sanitizer detectionAlexandru Croitor2020-06-151-0/+5
| | | | | | | | | | | | | | | The change fixes the labels to show up correctly in the configure summary. It also allows enabling the sanitizer via the feature flags, e.g. -DFEATURE_sanitize_address=ON. Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra so that repos built after qtbase have the same sanitizer options enabled. Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12 Fixes: QTBUG-84721 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Generate .prl files for plugins in static Qt buildsJoerg Bornemann2020-06-151-4/+7
| | | | | | | | | To successfully link plugins of a static Qt build into a Qt project we need to generate .prl files for the plugins. Task-number: QTBUG-84781 Change-Id: I1406052f2269050aa7cbe6aa2b546bece1c68467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Save OPENSSL_ROOT_DIR in QtBuildInternalsExtraAlexandru Croitor2020-06-081-0/+10
| | | | | | | | | | | This is needed so that other repos other than qtbase (like qtopcua) can still find_package(WrapOpenSSL) successfully. The path needs to be converted to a CMake path, to avoid issues on Windows with backslashes. Change-Id: I3d7652d93110f6b8f39a58a6c28aef6c7471aea7 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Make it possible to build tools when cross-compilingLeander Beernaert2020-06-021-0/+5
| | | | | | | | | | | | | | | | | | | This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "CMake: Don't create *Depends header for header-only modules"Joerg Bornemann2020-05-201-2/+1
| | | | | | | | | | | | This reverts commit e875f458055d6a7b54d2d853590ccc2495ab145b. Reason for revert: syncqt creates a master header that includes the *Depends header. Therefore we must always create the *Depends header. Ignore for now that *Depends headers are empty and pointless for module headers. Change-Id: I1dcc836788b3d46c4f1b504d2d64e9eb67b66206 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Default to building all configurations with Ninja Multi-ConfigAlexandru Croitor2020-05-191-1/+4
| | | | | | | | | | Thus we will build both Release and Debug configurations in Coin when cmake --build . is executed, mimicking qmake's make which builds both configurations in debug_and_release. Task-number: QTBUG-80900 Change-Id: If48aca249eb84e690d3f9d51a733b3a25df1f7ca Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow using single config generators after building with NMCAlexandru Croitor2020-05-191-9/+46
| | | | | | | | | | | | | | | | | | | | | | | | Where NMC is the CMake Ninja Multi-Config generator. The first use case is to allow building standalone tests with one configuration even if Qt was build with multiple configurations. Another use case is for regular Qt consumers that might use the generated qt-cmake shell script which does not have the generator specified (as opposed to qt-cmake-private). Another detail is to use the first configuration from the initial Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building standalone tests with a single config generator, so that it doesn't default to Debug, but rather to the provided first configuration. This matches qmake behavior, where on Windows with a debug_and_release configuration, tests are still built against release. Task-number: QTBUG-80900 Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't create *Depends header for header-only modulesJoerg Bornemann2020-05-161-1/+2
| | | | | | | | | Set the target property INTERFACE_MODULE_IS_HEADER_ONLY for header-only modules, and only create *Depends header files if this property is falsy. Change-Id: Ic6b100787d18b3ff1f7b9d0f2b5c744018b1f295 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add MODULE_INCLUDE_NAME one-value-keyword to qt_add_moduleJoerg Bornemann2020-05-151-3/+3
| | | | | | | | | | | | This value is the equivalent of qt_module.prf's MODULE_INCNAME and can be used to specify a name for the module's include subdirectory. The default is Qt<ModuleName>. The include name is stored in the module's target property MODULE_INCLUDE_NAME. Change-Id: Ie6c8f6882ee2c3db78884ae5781593c803be3c05 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Generate qmake .prl filesJoerg Bornemann2020-04-171-0/+6
| | | | | | | | 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: Handle automatic rpath embedding correctlyAlexandru Croitor2020-04-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using CMAKE_INSTALL_RPATH to embed an absolute path to prefix/libdir into all targets, use the more sophisticated aproach that qmake does. For certain targets (modules, plugins, tools) use relative rpaths. Otherwise embed absolute paths (examples, regular binaries). Installed tests currently have no rpaths. On certain platforms rpaths are not used (Windows, Android, iOS / uikit). Frameworks, app bundles and shallow bundles should also be handled correctly. Additional rpaths can be provided via QT_EXTRA_RPATHS variable (similar to the -R option that configure takes). Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF or QT_DISABLE_RPATH=ON. Note that installed examples are not relocatable at the moment (due to always having an absolute path rpath), so this is a missing feature compared to qmake. This is due to missing information on where examples will be installed, so a relative rpath can not be computed. By default a Qt installation is relocatable, so there is no need to pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R . Relative rpaths will have the appropriate 'relative base' prefixed to them (e.g $ORIGIN on linux and @loader_path on darwin platforms). There is currently no support for other platforms that might have a different 'relative base' than the ones mentioned above. Any extra rpaths are saved to BuildInternalsExtra which are re-used when building other repositories. configurejson2cmake modified to include correct conditions for the rpath feature. It's very likely that we will need a new qt_add_internal_app() function for gui apps that are to be installed to prefix/bin. For example for Assistant from qttools. Currently such apps use qt_add_executable(). The distinction is necessary to make sure that relative rpaths are embedded into apps, but not executables (which tests are part of). Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix auto-detection of precompiled header supportAlexandru Croitor2020-03-251-0/+4
| | | | | | | | | | | | 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 <simon.hausmann@qt.io>
* CMake: Handle path components like INSTALL_LIBDIR more correctlyAlexandru Croitor2020-03-101-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | We recomputed INSTALL_LIBDIR for every new repo that is configured, which is incorrect due losing any custom provided libdir when configuring qtbase. Save that information (and all other path components) in QtBuildInternalsConfigExtra.cmake. Make sure not to-recompute that information when configuring a project other than QtBase. Allow providing absolute paths instead of relative paths for these variables. Note that only absolute paths pointing somewhere under the prefix will currently work, otherwise configuraion will fail. If we need to support such a use case, we'll have to carefully check all code that use these path components to make sure they handle absolute paths correctly (current assumption is relative paths everywhere). Use the computed paths when generating the qconfig.cpp file which is used for qmake -query. Task-number: QTBUG-81289 Change-Id: I331aa00e47988fe0ee4e533b5f95c4df11c4d96f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add QT_MODULE_SKIP_MODULE_INCLUDES propertyLeander Beernaert2020-03-051-0/+9
| | | | | | | | | | When a Qt module has this property set, when we generate the QtModuleDepends header file and find this module it will not be added. This is required to be able to create a Core_qobject module, as it does not have any headers. Change-Id: Iaea1080919d05ace12e48693e02d8c0f4c669339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Adapt to latest upstream Ninja Multi-Config changesAlexandru Croitor2020-03-041-5/+5
| | | | | | | | Most of the NMC-specific variables were renamed to be more general. Change-Id: I8ee2874fecb9e57480ce51db9183c6cf3dd100af Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow building bundled 3rd party libraries in qtbaseAlexandru Croitor2020-02-251-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Only export public module link dependencies for shared buildsLeander Beernaert2020-02-121-1/+3
| | | | | | | | | Unless we are building under a static library configuration there is no reason to export the dependency on private libraries. Change-Id: I724da38495dc55cc2783d4b19c01533fc0900d22 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
* Fix CMAKE_BUILD_TYPE to be force setAlexandru Croitor2020-01-301-1/+5
| | | | | | | | | | | Otherwise CMake sets an up an empty default value itself, and then the value in QtBuildInternalsExtra does not end up being used, and then QtSetup ends up setting a Debug value. Amends 34a112e383d4ce3f6fe7417c1873fd3b33176032 Change-Id: If97a1d8c19ad5e7f690283997ff80dd9588cd521 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix CMAKE_BUILD_TYPE to be a cache variable in QtBuildInternalsExtraAlexandru Croitor2020-01-291-1/+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>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Provide a way to specify extra tool package dependenciesAlexandru Croitor2019-11-261-19/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the qtwayland repo, both WaylandClient and WaylandCompositor packages need access to the qtwaylandscanner tool. That means that the add_qt_tool(qtwaylandscanner) can't use the TOOLS_TARGET argument to associate a dependency with only one of the above modules. Instead add_qt_tool now allows specifying a non-existent module name for the TOOLS_TARGET argument, which can be manually depended on by other packages. Actually, you could specify the non-existent module before as well, but that didn't do everything that had to be done. This required a bit of refactoring in how the Dependencies file for Tools packages is created. Now the file is created in qt_export_tools. Two new functions were also added to allow recording additional dependencies between packages. Also some bug fixes were done to make it all work. Specifically the _FOUND variable generated in the Dependencies file was incorrect. Also there are some quotes missing when appending extra package dependencies via the QT_EXTRA_PACKAGE_DEPENDENCIES property. Change-Id: I167efec16dff8d036e191df3572ea72764e22bc5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Don't install QtFooTestsConfig.cmake if no modules were builtAlexandru Croitor2019-11-121-0/+6
| | | | | | | | | | | | | | | When configuring qtx11extras on macOS, we ended up installing the file, which made Coin think that at least one module was built, and thus it tried to build tests as well. Don't install the file if no modules were built, thus preventing from trying to build tests in Coin. Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Change-Id: I920a0b40a6ded12140f251352da53b68eef6560d Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix architecture config tests values to be written only onceAlexandru Croitor2019-11-081-1/+1
| | | | | | | | | | | | | | | | Every time the qtbase project was reconfigured, the list of config tests results was appended to a cache variable which was never reset, resulting in multiple copies of the same values being written to QtBuildInternalsExtra.cmake. Make sure to clean the cache variable before appending to it. Also change the variable to be all upper-case, to be consistent with other cache variables. Change-Id: Ic12046730a080595e19377981a726bc330641dc1 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Make standalone tests build via top level repo projectAlexandru Croitor2019-11-081-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QtPostProcess: Check target link-type when collecting depsMårten Nordheim2019-09-301-4/+11
| | | | | | | | Fixes a configure issue in qtgamepad Change-Id: I8212d6d58fd2f28ae71a9559cf6544102a873718 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* Create module tools packages (config files) automaticallyAlexandru Croitor2019-09-221-0/+8
| | | | | | | | | | | | | | | | | | | | | 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 <simon.hausmann@qt.io>
* Fix unnecessary find_package calls for shared builds, part 2Simon Hausmann2019-09-061-1/+1
| | | | | | | | Fix the silly boolean logic error in commit 9c1b7802d7f118b55ccc04dab74e1ee19e6d429f. Change-Id: I9dd0d3e8be5cbe75583099686a623d81d3dd87fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Avoid unnecessary find_package calls when using Qt with shared buildsSimon Hausmann2019-09-051-0/+5
| | | | | | | | | | | | Don't create the plugin config files when doing shared builds, otherwise for example Qt6GuiPlugins.cmake will try to include the xcb plugin cmake config, which in turn will perform a full-fledged find_package series to locate xcb. When an application just uses find_package(Qt6Gui), then that is not needed. Change-Id: I1890aaa5be8e214151c65fa981f547a73c0ca7fc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* Add support for Qt header_modules aka a header only INTERFACE libraryAlexandru Croitor2019-08-231-3/+19
| | | | | | | | | | Also add support for modules that have no private module counterpart. Both are needed for Designer's QtUiPlugin in qttools. Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
* Add some clarifying documentation in QtPostProcessAlexandru Croitor2019-08-231-0/+13
| | | | | | | | | | Specifically what each of the list variables in qt_internal_create_module_depends_file is used for. Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Fix creation of ModuleDepends header file with correct dependenciesAlexandru Croitor2019-08-231-1/+3
| | | | | | | | | | The content of the generated header files should reference both public and private Qt module dependencies. This is the same as what qmake does. Change-Id: I2e47c93291d677b86af7bb80fb788b2acf939743 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot
* Abstract and fix usages of QT_KNOWN_MODULESAlexandru Croitor2019-08-231-7/+13
| | | | | | | | | | | | | | | | | In some places of the build system we need to iterate over repo specific Qt known modules (aka the ones that are built in the current project). In other places we need to iterate over the whole list of known Qt modules (those found via find_package + the ones built in the current project). Introduce two separate functions that provide access to either the former or latter, and adjust all existing usages of QT_KNOWN_MODULES as needed. Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Export architecture config test variablesLeander Beernaert2019-08-141-0/+4
| | | | | | | | | Export the architecture configuration variables from QtBase. There are other modules that require access to this information in order to enable certain features (e.g: qml_jit in QtDeclarative). Change-Id: If2c7f29ccb1c0b0a0db3d78ad133a2a6be12b5ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Ugly fix for handling QT_SOURCE_TREEAlexandru Croitor2019-07-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf. In qtbase, it's used throughout various projects to find cpp sources when building standalone tests (among other things). Everything works fine with qmake, because even if qmake is invoked on the tests subfolder, qmake searches up the source directory tree until it finds a .qmake.conf file, and uses that. When building qttools with qmake, the qdoc project expects to have a QT_SOURCE_TREE value, but it's not actually set in the qttools/.qmake.conf file, so the generated include paths that use that value are incorrect. Curiously the build still succeeds. Now in CMake land we replaced QT_SOURCE_TREE with CMAKE_SOURCE_DIR, but that does not work properly when doing a standalone tests build, because the project in that case is the tests one, and not the qtbase one, so configuration fails in a developer build when trying to configure some private tests. So far I've found that only qtbase actively uses this value. A temporary fix is to save the qtbase source directory into a QT_SOURCE_TREE variable inside the generated BuildInternalsExtra.cmake file. The pro2cmake script is changed to handle presence of QT_SOURCE_TREE in a qrc file path. This is handled by finding the location of a .qmake.conf file starting from the project file absolute path. This is needed to stop the script from crashing when handling the mimedatabase test projects for example. The change also regenerates the relevant failing test projects, and thus standalone tests (when doing developer builds aka private_tests enabled) now configure and build successfully. Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: allow client apps to load static plug-insJean-Michaël Celerier2019-07-051-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 19:51:04 +0000