summaryrefslogtreecommitdiffstats
path: root/cmake/QtPostProcess.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Android: Final changes for APK generationLeander Beernaert2019-06-261-0/+12
| | | | | | | | | | | | | | | | | | | | Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix static buildsAlexandru Croitor2019-06-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | There were a few issues: - Third party dependency info for plugins was not generated, because the depends and public_depends variables were not fetched. This caused issues when trying to use the qcocoa plugin in a consuming application, because Cups::Cups was not found. - Privately linked libraries in extend_target were not considered when generating dependency info for modules. This caused issues in QtThemeSupport, becauese it could not find Qt::DBus, due to that target only being added as a private library in a conditional scope. - Make sure to handle privately linked internal modules like PlatformModuleInternal to map to the Qt5 package, because there is no standalone package for it. Also remove a TODO comment that says that qt_register_target_dependencies should maybe be called in extend_target. That's already the case. Change-Id: Ie99c52e800cd89e6f82008f1e38f4da5cd602929 Reviewed-by: Qt CMake Build Bot Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Make WinMain linkage compatible with Qt 5Simon Hausmann2019-06-121-0/+5
| | | | | | | | | | | | | | | | | | | | In Qt 5, the Qt5Core target was extended by Qt5CoreConfigExtras.cmake to have a generator expression as interface linkage that would conditionally link WinMain. This patch implements the same through regular interface linkage right in corelib. Since the linkage happens through a generator expression, our dependency generator does not see this as a dependency. Therefore we add this as an unconditional package dependency for corelib, on Windows. In theory this could be done also in winmain's CMakeLists.txt, as targets can be extended outside of their directory. However this adds a directory id (WinMain:@<023423>) to the linkage, which mysteriously is not removed on the exported core target. Change-Id: If2abb9ba790f51274f582c9ec28c13d968b84302 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* cmake: Generate QtBuildInternalsExtra at conftimeKevin Funk2019-06-051-28/+5
| | | | | | | ... using configure_file. Change-Id: Ibe3522c33e20a86c454b23919547775624f84755 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: register plug-ins, create dependencies fileJean-Michaël Celerier2019-06-041-125/+217
| | | | | | | | This commit introduces infrastructure work to allow static builds of Qt to handle importing of plug-ins. Change-Id: Ife0ca3ca7276ea8ec96fe0eb6adf934fad7620ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Reset main_module_tool_deps in QtPostProcessAlexandru Croitor2019-05-221-0/+1
| | | | | | | | | | | The variable was not reset when interating through all the Qt targets, which resulted in QtTest wronlgy depending on QtWidgetTools. Task-number: QTBUG-75875 Change-Id: I24da495fa53e9163992a1ed53f5cd7e1c6da5e51 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Allow building the tests directory as a standalone CMake projectAlexandru Croitor2019-05-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Save and set the CMAKE_INSTALL_PREFIX in BuildInternal's Config fileAlexandru Croitor2019-05-151-0/+6
| | | | | | | | | | | | | | Once qtbase is built and installed, save the CMAKE_INSTALL_PREFIX that was used during the build, and set it when a consumer calls find_package(Qt5BuildInternals). This fixes a bug where syncqt can not be found when building qtsvg, while the developer specifies CMAKE_PREFIX_PATH to find the Qt packages, but does not set the CMAKE_INSTALL_PREFIX. Task-number: QTBUG-75544 Change-Id: I03fd23ba418af5115105610f3f9ed92664562945 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Use the qt_build_repo() macros for building qtbase as wellAlexandru Croitor2019-05-151-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Implement developer / non-prefix buildsAlexandru Croitor2019-05-151-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Handle generating find_dependency() calls for nolink targetsAlexandru Croitor2019-05-031-0/+8
| | | | | | | | | | | | | | | | Previously we just recorded that Gui has to link against Vulkan::Vulkan_nolink, but if an application consumed Gui, it wouldn't find that target. We need to record that if a module links against Vulkan_nolink, and then generate a find_dependency(Vulkan) call in the module config file. We also have to assign the _nolink interface library to an export (the Qt5 one), so that it gets installed as a target. Change-Id: Icbc29ff4161ab18fdd162196ae128e29c1ee8c80 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: move dependencies accumulation in QtPostProcess.cmakeJean-Michaël Celerier2019-05-031-1/+23
| | | | | | | | | This is needed because dependencies added after add_qt_module with extend_target are currently not taken into account. Task-number: QTBUG-75538 Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make module package depend on its own tool packageAlexandru Croitor2019-05-021-2/+36
| | | | | | | | | | | | | | | | | | | | Also make the tool package depend on all tool packages that correspond to the qt module dependencies. So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools). And find_package(Qt5WidgetsTools) will call find_package for Qt5GuiTools, and Qt5CoreTools. This enhances the user experience, so that in modules like qtsvg, you don't have to specify both find_package(Qt5Widgets) and find_package(Qt5WidgetsTools), but only the former. Or when cross building, you only need to specify Qt5WidgetTools, to get both Core and Gui tools. Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Write find_dependency() calls in Qt Module config filesAlexandru Croitor2019-05-021-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces a new function called qt_find_package() which can take an extra option called PROVIDED_TARGETS, which associates targets with the package that defines those targets. This is done by setting the INTERFACE_QT_PACKAGE_NAME and INTERFACE_QT_PACKAGE_VERSION properties on the imported targets. This information allows us to generate appropriate find_dependency() calls in a module's Config file for third party libraries. For example when an application links against QtCore, it should also link against zlib and atomic libraries. In order to do that, the library locations first have to be found by CMake. This is achieved by embedding find_dependency(ZLIB) and find_dependency(Atomic) in Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake. The latter is picked up when an application project contains find_package(Qt5Core), and thus all linking dependencies are resolved. The information 'which package provides which targets' is contained in the python json2cmake conversion script. The generated output of the script contains qt_find_package() calls that represent that information. The Qt5CoreDependencies.cmake file and which which dependencies it contains is generated at the QtPostProcess stop. Note that for non-static Qt builds, we only need to propagate public 3rd party libraries. For static builds, we need all third party libraries. In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any scope, the targets on which the property is set, have to be GLOBAL. Also for applications and other modules to find all required third party libraries, we have to install all our custom Find modules, and make sure they define INTERFACE IMPORTED libraries, and not just IMPORTED libraries. Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Export tool config and target files for each relevant moduleAlexandru Croitor2019-05-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Fix header Depends file generationAlexandru Croitor2019-03-111-0/+1
| | | | | | | | The script used to write incorrect dependency headers due to not clearing the qtdeps variable at each loop step. Change-Id: Icf293be7cea596daa096ab19d390c0bb468a8654 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* QtPostProcess: Fix generation of *Depends header filesTobias Hunger2018-11-011-1/+14
| | | | | | | | Normalize Qt module names before trying to match them. Deduplicate the names while at it. Change-Id: I5821c34fe5904cf9e9b986ac3ae4af2b248466b7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Begin port of qtbase to CMakeSimon Hausmann2018-11-011-0/+32
Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 00:30:59 +0000