summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleConfig.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Refactor Metatypes dependency propagationLeander Beernaert2020-02-101-21/+0
| | | | | | | | | | | | | | | | Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Load module specific extensions for QtBuildInternalsLeander Beernaert2020-02-061-0/+6
| | | | | | | | | | | | This patch enables each module to load their own Qt${version}ModuleBuildInternals.cmake to expose module specific features when building Qt. These scripts are only loaded when the package QtBuildInternals has been loaded. Change-Id: Ie58dd93ddd292cf106fe7ef147151a51fd5aa2b1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Generate metatypes dependency fileLeander Beernaert2020-01-291-0/+22
| | | | | | | | | | | | | | | | Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-8/+1
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix creation of versionless targets for toolsAlexandru Croitor2019-12-061-1/+3
| | | | | | | | | | | | | | | | | | We can't use qt_internal_export_modern_cmake_config_targets_file for executables like tools, because it's not possible to use INTERFACE_LINK_LIBRARIES with executables like you can with libraries. We also can't create aliases to non-global imported targets. Instead create new imported executable targets, fish out the imported location, and assign it to the versionless targets. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Task-number: QTBUG-75984 Change-Id: I6a3c9c67ef4699c72a6c9a627c63158dfd6557f8 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't query MODULE_PLUGIN_TYPES property on interface librariesAlexandru Croitor2019-11-081-3/+7
| | | | | | | | | | | | | The reason is that interface libraries have to have properties prefixed with INTERFACE_ and more importantly we don't set the property for interface libraries at the moment. Amends d1542e8a73f535011d42970cc5b1b28a414c14c9. Change-Id: I86bf99995278b9086fa0e3815e10d5d54d9ea4dc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Match qt_import_plugin API with qt5'sJean-Michaël Celerier2019-10-091-0/+5
| | | | | | | | | | Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Fix examples find_package calls to work in prefix buildsAlexandru Croitor2019-09-211-1/+1
| | | | | | | | | | | | | | | | | | | To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix creation of generated plugin cpp files in static buildsAlexandru Croitor2019-07-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | When building qtdeclarative against a static iOS qtbase build, QtNetwork is find_package'd twice, once in the top level CMakeLists.txt file, and once by the qtuiotouchplugin which has Network as a dependency. This meant that the static plugins that Network exposes had auto import cpp files generated twice, which failed the configuration of qtdeclarative. To fix this, don't generate the same file more than once. To do that, protect the inclusion of the FooPlugins.cmake file, to only be included once in every directory scope. That can be achieved by setting a variable to TRUE when the target does not exist yet. If the target exists in the same scope, that means that find_package() was called a second time in the same scope, so there is no need to include the Plugins file. Change-Id: I9d7c3e7b7c22c2b4526cf1d717b9d15919f213f3 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix linking of examplesSimon Hausmann2019-06-121-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Collect more known modules when considering private libraries inAlexandru Croitor2019-06-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | extend_target. In extend_target(Foo) we go over all the ModulePrivate dependencies to assign them to FooPrivate. To do that we use the QT_KNOWN_MODULES variable. The problem is that the variable gets reset when we build a new repository, so when we build qtdeclarative, QT_KNOWN_MODULES has no entries for Core, Gui, etc, but only Qml, Quick, etc. And yet QmlPrivate has to depend on CorePrivate. Change the module Config.cmake files to append their target name to a global variable called QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE. The global variable gets populated every time find_package(QtFoo) is called. Use the union of QT_KNOWN_MODULES and QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE when considering FooPrivate libraries. Change-Id: Ibd9449744478cea58eb5d9737cc8887b4df92420 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Allow to build examples as standalone projectKevin Funk2019-06-051-6/+8
| | | | | | | | | | | | | | | | Create CMake config files which can be used from the very same CMake project. These CMake config files simply do not create any targets, controlled via the QT_NO_CREATE_TARGETS. This patch also allows to build qtbase.git:examples as a standalone project, against an already-built Qt. Ran this: ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example Task-number: QTBUG-74713 Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: register plug-ins, create dependencies fileJean-Michaël Celerier2019-06-041-1/+5
| | | | | | | | 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>
* Propagate QT_CMAKE_EXPORT_NAMESPACE via QtCore packageAlexandru Croitor2019-05-171-0/+4
| | | | | | | | | | | | | | | | QT_CMAKE_EXPORT_NAMESPACE is used by the Qt packages to make features available to the consuming CMake project. The value was moved to the BuildInternals Config file, but that's wrong because consuming applications not including the BuildInternals component would fail to use any other Qt package. Move QT_CMAKE_EXPORT_NAMESPACE to be propagated with QtCore package again. Amends 9542e78525b422159406d8fa63e30dcd0f926411. Change-Id: I9841ac8c2828b00c0111d59e8976c889554e0ce1 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Use the qt_build_repo() macros for building qtbase as wellAlexandru Croitor2019-05-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmake: Generate config files with Qt:: prefixKevin Funk2019-05-031-0/+2
| | | | | | | | Generate CMake config files which export Qt targets with a Qt:: prefix (i.e. without a major version suffix in the namespace) Change-Id: Ia07f98be6d0e24c196e3880b7469f1f0c6232c06 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: move dependencies accumulation in QtPostProcess.cmakeJean-Michaël Celerier2019-05-031-18/+0
| | | | | | | | | 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>
* Write find_dependency() calls in Qt Module config filesAlexandru Croitor2019-05-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmake: Minor fix in QtModuleConfig.cmake.inKevin Funk2019-02-141-1/+1
| | | | | Change-Id: Ia01e935582b5291fa8ed6bf46866fbb74d41f4b0 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Start to use ConfigExtra.cmake filesKevin Funk2019-02-121-3/+3
| | | | | | | | | | | | | | Enables the use of e.g. QT_NO_DEBUG in compiler flags, -fPIC, passing on of QT_NAMESPACE, etc. pp. Dropping a lot of custom code which handled adding imported targets for the command-line tools (this is all being handled by CMake already). It needs to be investigated if we need to resurrect Qt5GuiConfigExtras.cmake.in in one way or the other. Change-Id: I4fa141b68fddaad4f33e628c59d5d0b3a7b3a096 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Create Qt5 compat targets in config filesKevin Funk2019-02-121-1/+1
| | | | | | | | For now create targets a la "Qt5::Core" to stay compatible with the current Qt5 naming scheme. The name is controllable via a CMake option. Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Make find_package(Qt5 ...) work properlyKevin Funk2019-02-111-6/+27
| | | | | | | | | | | | | Introduce a new cached variable INSTALL_CMAKE_NAMESPACE for defining the prefix used for CMake config files (c.f. "${PREFIX}Core/${PREFIX}CoreConfig.cmake") Also make sure to `find_dependency(...)` the required packages inside the individual CMake config files. I.e. in Qt5WidgetsConfig.cmake, search for Qt5Core, etc. pp.. Change-Id: Idc027925fe9d5323091c4853803ad5ce44b1afc6 Reviewed-by: Jean-Michaël Celerier <jean-michael.celerier@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* CMake: Store Qt features in CMake CacheTobias Hunger2019-01-171-3/+7
| | | | | | | | | | This is less self-contained than what we have, but significantly speeds up cmake configure/generate runs. This patch also warns when a feature is already defined. Change-Id: I8cab63e208ba98756b47d362a39b462f5ec55e20 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Begin port of qtbase to CMakeSimon Hausmann2018-11-011-0/+9
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-09 19:02:10 +0000