summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleConfig.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Introduce QT_DEBUG_FIND_PACKAGE for troubleshootingAlexandru Croitor2022-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | When a Qt component or dependency is not found, we will now show a message that the user can reconfigure the project with -DQT_DEBUG_FIND_PACKAGE=ON. If the option is enabled, various variables that find_package uses to find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be recorded before each find_package / find_dependency call that is executed in any of the Qt package files. If any find_package call fails (a package has its _FOUND variable set to 0), the values of all those recorded variables will be shown. This is useful to troubleshoot issues, especially when cross-compiling, without having to manually modify the various Config files. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Suggest hints on how to debug missing packagesAlexandru Croitor2022-07-181-0/+2
| | | | | | | | | | | | | | | | | | | | | Depending on CMake version suggest usage of either --debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot why dependent packages are not found. To achieve that, append the hint message to the _NOT_FOUND_MESSAGE. To ensure it works for qt dependencies, and not only tool and 3rd party dependencies, _qt_internal_find_qt_dependencies is modified to set variable names infixed by the target name, so the name is consistent with the other dependency lookup functions. The check and message are also added when a Qt6 component is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Remove dead codeAlexandru Croitor2022-07-181-1/+1
| | | | | | | | | | | | It was accidentally left when changes were made from patchset 1 to patchset 2 in 825cb50c27fc0942a76771f9fb2ec052dc9142bf Amends 825cb50c27fc0942a76771f9fb2ec052dc9142bf Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I04dd50cfb93655f0c224bb226695e7771e9bc5d1 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't create targets if dependencies are not foundAlexandru Croitor2021-11-021-1/+1
| | | | | | | | | | | | | | | | | | If one of the dependencies in QtFooModuleDependencies.cmake is not found, QtFoo_FOUND will be set to False by find_dependency. In that case, we should not create imported targets that belong to that package. It would be misleading for projects that do target existence checks instead of package_FOUND checks as well as generally being incorrect. The created imported targets might be referencing other targets that would not exist. Pick-to: 6.2 Fixes: QTBUG-97896 Change-Id: I09198aa3f19be047b27c29329b6e62c30fa09dc0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Craig Scott <craig.scott@qt.io>
* Revert "CMake: Warn if cmake_minimum_required has an unsupported low version"Alexandru Croitor2021-10-041-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 657525965b86cfa135bb5a814a537443163acb14. The change relied on reading the last value of the CMAKE_MINIMUM_REQUIRED_VERSION variable before one of the Qt packages is found to use it for the version check. Even if a user project has a cmake_minimum_required() right at the beginning of the project with a supported version specified, the first project() call which loads a CMake toolchain file could contain another cmake_minimum_required() call with a lower (unsupported) version and that version would be used for the check, failing the project configuration. The Android NDK ships such a toolchain file, which requires version '3.6'. Thus, relying on the last value of CMAKE_MINIMUM_REQUIRED_VERSION is not robust enough. Pick-to: 6.2 Task-number: QTBUG-95018 Task-number: QTBUG-95832 Change-Id: Iff3cb0a46e6e878569dce9c5fe915a714a034904 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Warn if cmake_minimum_required has an unsupported low versionAlexandru Croitor2021-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Qt6Config.cmake calls cmake_minimum_required to ensure a recent enough CMake version is used in projects. That call does not set policies in the calling subdirectory scope, because find_package introduces a new policy scope. If a project using Qt has a 'cmake_minimum_required(VERSION 3.1)' call and is configured with a recent CMake, many policies will still be set to OLD. One such policy is CMP0071 (Run AUTOMOC on GENERATED files). The policy value is queried at generation time rather than at target definition time, which means we can't influence the policy value (e.g. inside the implementation of qt_add_executable for example) The inability to influence the policy value for targets created by our own CMake functions is unfortunate and can lead to issues (in the case of the above policy to compilation / linker issues). Record the version of the last cmake_minimum_required call before the Qt packages are found and error out if the version is lower than the minimum supported one. A project can reduce the error into a warning by specifying a -DQT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT_IN_CMAKE_MIN_REQUIRED=3.xyz option when configuring the project. If the option is used and build issues arise, no official support is given. All the CMake example projects shipped with Qt specify a minimum version of 3.16 already (which is the minimum for shared Qt builds), so it shouldn't be an issue to require that in other user projects as well. Implementation wise, we follow the existing pattern to record what the minimum and computed versions for static and shared Qt builds are at qtbase configure time. These are then checked before the Qt6 or QtFoo packages are find_package'd. Amends 6518bcc167d47e1c27d082c21551b9a838b04e5d Pick-to: 6.2 Task-number: QTBUG-95018 Task-number: QTBUG-95832 Change-Id: I1a1d06d82f566c92192a699045127943604c8353 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Improve component / package not found error messagesAlexandru Croitor2021-08-061-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide better error messages when a Qt package / component is not found. Mention the location of the expected Config file on the file system, whether it exists Also mention the location of the Config file that was specified by the user when configuring the project or which CMake computed and stored in QtModule_DIR cache var. Mention that a package is not found in case if the main target exposed by that package is not found. If the target is not found, mention that it might be due to QT_NO_CREATE_TARGETS being set to TRUE (when it is set to true). If it is set to true, the assumption is that the target must have been defined by something else before the find_package call (either an earlier find_package call without QT_NO_CREATE_TARGETS set to TRUE or maybe it's the use case of Qt being built together with its examples or it's a super build). Unset _Qt_NOTFOUND_MESSAGE to ensure that the Qt6 not found error message is not spilled into any subsequent find_package(Qt6) calls, causing a cascade of unwarranted warnings / errors. Make sure to unset it only if components were specified, so the message is not shown or unset in any of the recursive find_package(Qt6) calls which is a dependency for regular Qt module packages. This works fine, because find_package(Qt6) calls with components are only done in project code and not done by the transitive dependency code (which looks for Qt6Foo packages directly). Remove some dead code. Pick-to: 6.2 Task-number: QTBUG-95532 Change-Id: Ie93d18e25e33aa0fe9e9da9a60e3d3e4cd6adb58 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-111-2/+0
| | | | | | | | | | | | | | | | | | | | Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add detection of FEATURE_foo change by userAlexey Edelev2020-12-171-19/+23
| | | | | | | | | | | | | | | | | | | | | Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix build of Release user projects against RelWithDebInfo QtJoerg Bornemann2020-09-251-0/+1
| | | | | | | | | | | | | | | | | | | | | Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Revert "Revert "CMake: Fix usage of find_dependency()""Joerg Bornemann2020-09-141-1/+6
| | | | | | | | ...and fix the build errors the original change caused. This reverts commit 127fb8bb5587db52216d0ac934f3111170a7cbe3. Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Provide old style CMake variables for target infoAlexandru Croitor2020-07-171-0/+56
| | | | | | | | | | | | | | | | | | | | | 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>
* 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-06-01 15:53:46 +0000