summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* qt_internal_add_module: Document HEADER_MODULE and STATICFabian Kosmale2021-11-261-0/+8
| | | | | | Task-number: QTBUG-94863 Change-Id: If52ed7e17ea77d8cb6e0255e988feb0b1bd0aa76 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move qt_finalize_framework_headers_copy to the scope finalizerAlexey Edelev2021-11-031-4/+1
| | | | | | | | | | | | | | The qt_finalize_framework_headers_copy function uses the module QT_COPIED_FRAMEWORK_HEADERS property to generate the dependency list for the ${target}_framework_headers target. In a common case elements can be added to the QT_COPIED_FRAMEWORK_HEADERS property after the qt_internal_add_module command call, that's why we need to make sure that qt_finalize_framework_headers_copy is called after collecting all headers assigned to the module. Pick-to: 6.2 Change-Id: I2878fa6b8d4b11677c3f48345bf6e239221074c2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow disabling package version checkAlexandru Croitor2021-10-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building Qt repos, all find_package(Qt6) calls request a PROJECT_VERSION version which is set in .cmake.conf via QT_REPO_MODULE_VERSION. This means trying to configure qtsvg from a 6.3 branch using a 6.2 qtbase won't work, because qtsvg will call find_package(Qt6 6.3) and no such Qt6 package version exists. There are certain scenarios where it might be useful to try to do that though. One of them is doing Qt development while locally mixing branches. Another is building a 6.4 QtWebEngine against a 6.2 Qt. Allow to opt out of the version check by configuring each Qt repo with -DQT_NO_PACKAGE_VERSION_CHECK=TRUE. This setting is not recorded and will have to be set again when configuring another repo. The version check will also be disabled by default when configuring with the -developer-build feature. This will be recorded and embedded into each ConfigVersion file. If the version check is disabled, a warning will be shown mentioning the incompatible version of a package that was found but that package will still be accepted. The warning will show both when building Qt or using Qt in a user project. The warnings can be disabled by passing -DQT_NO_PACKAGE_VERSION_INCOMPATIBLE_WARNING=TRUE Furthermore when building a Qt repo, another warning will show when an incompatible package version is detected, to suggest to the Qt builder whether they want to use the incompatible version by disabling the version check. Note that there are no compatibility promises when using mixed non-matching versions. Things might not work. These options are only provided for convenience and their users know what they are doing. Pick-to: 6.2 Fixes: QTBUG-96458 Change-Id: I1a42e0b2a00b73513d776d89a76102ffd9136422 Reviewed-by: Craig Scott <craig.scott@qt.io>
* CMake: Make LTO build workThiago Macieira2021-10-131-1/+1
| | | | | | | | We don't need to check FEATURE_ltcg, just add -fno-lto unconditionally. That makes QtCore compile with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON. Change-Id: Icb2516126f674e7b8bb3fffd16ada2c71d7334aa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not generate cpp exports for pure STATIC modulesAlexey Edelev2021-09-171-1/+4
| | | | | | | | | | | Static libraries don't need to export their symbols, and corner cases when sources are also used in shared libraries, should be handled manually. Task-number: QTBUG-90492 Change-Id: I5cb0a3f7e280b042b678bdbe4475f2bbf9f6b9ba Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add explicit install rules for the autogenerated cpp exportsAlexey Edelev2021-09-171-8/+38
| | | | | | | | | | | | | | | | | | | If qt_internal_generate_cpp_global_exports is called outside the qt_internall_add_module function scope, install rule that is generated by qt_internall_add_module won't include generated cpp export header files. This adds the explicit file-based install rule for the generated cpp exports. Since qt_internal_generate_cpp_global_exports now encapsulates all install rules related to the generated cpp exports, no need to expose the generated filenames outside the function. It's expected that module public headers now could be added outside the qt_internal_add_module function. Tune generating of the module timestamp by replacing the DEPENDS value with generator expression. Task-number: QTBUG-90492 Change-Id: I0f086abc8187c5d51117c3a75c47b58580f6913f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Expose cpp export related arguments for qt_internal_add_module usersAlexey Edelev2021-09-161-43/+8
| | | | | | | | | | Functions that use qt_internal_add_module under the hood might need to generate cpp exports, e.g. qt_internal_add_qml_module. Append cpp exports related arguments to the qt_internal_add_module arguments set. Task-number: QTBUG-90492 Change-Id: I4fd539bd1d8be4d3e57ed5b1b88dd2dbc2f5ca24 Reviewed-by: Craig Scott <craig.scott@qt.io>
* Implement generating of private cpp exportsAlexey Edelev2021-08-271-21/+88
| | | | | | | | | | | | | | | | | | | | | | | | | Add the generating of private cpp exports for Qt modules. Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module that is the manual switch for private exports generator. Existing modules in qtbase doesn't follow any strict convention of using private cpp export. So there is no clue how to detect if generating of the private exports is required or not for the module. Use autogenerated private cpp exports in QtNetwork module. CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different meaning. The provided name is used as a base name for the private and non-private headers that contains cpp exports. Header files suffixes are constant: .h and _p.h for the non-private and private header files accordingly. Pick-to: 6.2 Task-number: QTBUG-90492 Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use correct module include name across the projectAlexey Edelev2021-08-271-39/+144
| | | | | | | | | | | | | | | Module may have specific module include name that should be taken into account when specifying module include directories in different places. The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to the common naming rules and the property is used to preform include paths instead of the direct use of the module name. Add additional paths generated by qt_internal_module_info to keep them consistent across all cmake files. Pick-to: 6.2 Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Properly export MODULE_PLUGIN_TYPESAlexandru Croitor2021-08-261-0/+3
| | | | | | | | | | | | | | | | Don't export the MODULE_PLUGIN_TYPES property only when a module has an associated configure.cmake file with features. Instead, always export it if a module defines a plugin type. This fixes qttools DesignerTargets.cmake file to contain the plugin types it defines, given that the Designer lib does not declare any features via a configure.cmake file. Pick-to: 6.2 Task-number: QTBUG-95668 Change-Id: Ic036c31768e03b51d3bce9c2afe48e04f69f435b Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing PRIVATE_MODULE_INTERFACEs to INTERNAL_MODULEsAlexey Edelev2021-08-241-0/+4
| | | | | | | | | | | | | | To detect the internal module ouside the qt_internal_add_module function need to mark it with the property. This adds _qt_is_internal_module property to the Qt internal modules. Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private modules, INTERNAL_MODULEs is missing those dependencies if they were specified. Add extra condition to qt_internal_extend_target to link PRIVATE_MODULE_INTERFACE libraries to internal modules as well. Pick-to: 6.2 6.1 Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't install metatypes files for user projectsAlexandru Croitor2021-08-191-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Use _qt_module_has_headers instead of INTERFACE_MODULE_HAS_HEADERSAlexey Edelev2021-08-111-2/+0
| | | | | | | | | | | After introducing the _qt_module_has_headers target property, it's better to replace the INTERFACE_MODULE_HAS_HEADERS use by _qt_module_has_headers since properties duplicate each other. Pick-to: 6.2 Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Clean up and simplify qt6_extract_metatypes implementationAlexandru Croitor2021-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't propagate -fapplication-extension to user projectsAlexandru Croitor2021-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Use module interface name as OUTPUT_NAMEAlexey Edelev2021-07-131-1/+4
| | | | | | | | | | For internal modules we should keep the name of the file in file system consistent with previous Qt versions. Pick-to: 6.2 Fixes: QTBUG-95077 Change-Id: I02e4fced0fc3172e60f07bc7d1515e23744db567 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement generating of a module cpp export headerAlexey Edelev2021-06-241-6/+40
| | | | | | | | | | Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Cleanup temporary code related to internal modulesAlexey Edelev2021-06-211-9/+1
| | | | | | | | | Remove the temprotary 'Private' targets of the iternal modules. Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I9a2c7c8c2f63602476fd935b11dab7a835864537 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the naming of the config header files for private modulesAlexey Edelev2021-06-181-4/+11
| | | | | | | | | | | | | | | | | Perform a file name of the config header before adding a '_private' suffix. TODO: It makes sense to revisit the use of the CONFIG_MODULE_NAME variable since the variable is used for different purposes and mutate with use. Amends 8aee7c6b29be5a0ee7d5e7cfcb5f2db762b2e28b Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: Id5aaf8d423ec8b94afffe4641b54dab94b5453fb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix internal module naming in qmake .pri filesAlexey Edelev2021-06-171-0/+3
| | | | | | | | | | | | | Set the correct value to the _qt_config_module_name property at the internal module creating step instead of appending _private suffix when generating .pri files. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Pick-to: 6.2 Fixes: QTBUG-94568 Change-Id: I6fa8089358bc638668e313c98c3aee680bf7ec2a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Check the impact of static link order for user projectsAlexey Edelev2021-06-161-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix internal module mappings of the qtdeclarative repoAlexey Edelev2021-06-111-2/+2
| | | | | | | | Add 'Private' suffix to the internal module names in the mappings of the qmake files for modules of the qtdeclarative repo. Change-Id: I1592ebad0f0db553322ea766561b1b8c3fd38aea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make framework names consistent with the module namesAlexey Edelev2021-06-031-5/+5
| | | | | | | | | | | | | | | | | | For Apple's frameworks it's possible to include header files using the following assumption: If the framework name is "MyFramework" then '#include <MyFramework/frameworkheader.h>' will work without specifying the include path explicitly. This is broken for internal modules since they use the framework name with the 'Private' suffix. This uses the module name instead of the target name as a framework name. Amends edbe0eb335ca4c0fde23f57eae5acdf80937c9e3 Task-number: QTBUG-87775 Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move the framework related information to the common functionAlexey Edelev2021-05-311-9/+12
| | | | | | | | | | Since the information about framework is performed in multiple places it's quite hard to control its consistency. This moves the obtaining of framework related information to the common function and adjusts the use of the information across the repo. Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Use the correct framework name when preparing the framework pathsAlexey Edelev2021-05-271-1/+1
| | | | | | | | Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Task-number: QTBUG-87775 Change-Id: Ic79e77255e1f3aec9748a6770838f9eeeae94d38 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce a public qt_add_library functionAlexandru Croitor2021-05-251-14/+17
| | | | | | | | | | | | | | | | | | | | | | Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add export of the Private targets for the internal modulesAlexey Edelev2021-05-221-8/+6
| | | | | | | | | | | We need to export the Private targets of the internal modules to keep compatibility with existing internal module users across repositories. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Fixes: QTBUG-93943 Change-Id: I10234cec1eb618b69d041f80fbe29620a4e307b9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not expose Qt internals by the HEADER_MODULEsAlexey Edelev2021-05-201-1/+2
| | | | | | | | | | | | | | | | | | HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Pick-to: 6.1 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge main and private targets of the internal modulesAlexey Edelev2021-05-201-23/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-181-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Provide supported qt_internal_add_module() args via a functionCraig Scott2021-05-181-6/+46
| | | | | | | | | | This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* MSVC: define _CRT_SECURE_NO_WARNINGS for all internal CMake targetsLi Xinwei2021-04-201-4/+0
| | | | | | | | | | | | | | | | | In commit 013abe320680b3dcd3f6d7e4fb4880e590ba10e6, I add _CRT_SECURE_NO_WARNINGS definition for all Qt internal module targets, to suppress MSVC warnings like: warning C4996: 'strncpy': This function or variable may be unsafe. However, when compiling some internal tools, such as qmake and qdoc, such warnings also exist. To suppress this kind of warning entirely, _CRT_SECURE_NO_WARNINGS definition should be added for all Qt internal targets when using MSVC compiler. Pick-to: 6.1 Change-Id: I9c37b20672f9d0f470e3e9ea847e5221f43bfc04 Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Switch metatypes generation on by default for Qt modulesUlf Hermann2021-04-161-9/+19
| | | | | | | | | | We need the metatypes for anything directly or indirectly exposed to QML. Switching this on has no runtime overhead. For interface libraries we cannot generate any metatypes, though. Change-Id: I7b7f85bb4e16c28d00383c5c88b0f1c172c8d193 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* wasm: add cmake build supportLorn Potter2021-04-011-1/+3
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove some dead codeAlexandru Croitor2021-03-251-2/+0
| | | | | | | | | | The code was added as part of a6ccef651ddc075cf205bbd2693a26c08de6817a but the important bits were removed as part of c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Change-Id: I6ba7bffa2bfdbeae2c92cd9ffeaa5f31771eedde Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add plugins to Qt tools and executables for static buildsCraig Scott2021-03-231-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: make sure to collect Android dependencies for pluginsAssam Boudjelthia2021-03-171-1/+1
| | | | | | | | | | | | androiddeployqt relies on *-android-dependencies.xml files to know what dependencies like jar files and permissions a Qt module requires. CMake create those files under Qt prefix's lib dir but CMake was not accounting for module plugins. Fixes: QTBUG-90812 Pick-to: 6.1 6.0 Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Clear non-relevant CMake compiler flagsAlexey Edelev2021-01-271-2/+4
| | | | | | | | | | | | | | | | Add internal function to cleanup compiler flags out of the CMAKE_xxx_FLAGS_xxx variables. Use introduced interface to clear the '/EHsc' flag for the MSVC compiler family. This adjusts the CMake behavior to the qmake one. Change the 'EXCEPTIONS' option handling in helper functions. Add ability to add enabling and disabling exception flags. Previously it was only possible to add disabling exception flags. Fixes: QTBUG-89952 Change-Id: I60d47660a97ae9b5a1d1f4107d352c9e97890144 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Bail out in case syncqt failed to runKevin Funk2021-01-201-1/+4
| | | | | | | | | | | | | | Make sure to react on failed syncqt runs during the CMake run. CMake will now report something along this: ``` syncqt couldn't parse .../qt5/qtbase/sync.profile: Can't modify modulus (%) in scalar assignment at .../qt5/qtbase/sync.profile line 25, near ");" CMake Error at qtbase/cmake/QtModuleHelpers.cmake:192 (message): Failed to run syncqt, return code: 255 ``` Change-Id: I575a5fc926c547b6b633583e5d675f7e35beb734 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* QtEntryPoint: Fix linking Release against RelWithDebInfo with MSVCJoerg Bornemann2021-01-181-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To be able to link a Release user project against a RelWithDebInfo Qt we set several IMPORTED_*_RELEASE properties in the *AdditionalTargetInfo.cmake file of each Qt module. The EntryPoint module however is a bit special as it is an INTERFACE_LIBRARY linking publicly against a static library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file was almost empty, because qt_internal_export_additional_targets_file was called before EntryPointImplementation was set up. Also, qt_internal_add_module, which calls qt_internal_export_additional_targets_file, does not know that we want to export the EntryPointImplementation target. We fix this by telling qt_internal_add_module(EntryPoint) to not generate the *AdditionalTargetInfo.cmake file and call qt_internal_export_additional_targets_file later to take the targets EntryPoint and EntryPointImplementation into consideration. qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to turn off the generation of *AdditionalTargetInfo.cmake files. Pick-to: 6.0 Fixes: QTBUG-90039 Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Use -ffat-lto-objects for static libraries with ltcg and GCCChristophe Giboudeaux2021-01-131-0/+8
| | | | | | | | | | | | | | CMake <= 3.19 adds the '-fno-fat-lto-objects' compiler flag unconditionally when CMAKE_INTERPROCEDURAL_OPTIMIZATION is enabled. This is fine for shared libraries but static ones need the opposite compiler flag. Task-number: QTBUG-89426 Pick-to: 6.0 Change-Id: Ie5f48178803a270f6d94408f7a8e85d379eb123c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-0/+8
| | | | | | | | | | | | | | There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Avoid MSVC C4996 warningsLi Xinwei2020-12-041-0/+4
| | | | | | | | | | | | | | | | | The qmake build system defines _CRT_SECURE_NO_WARNINGS in mkspecs/features/qt_module.prf, the cmake build system should do the same thing in qt_internal_add_module(). Adding this definition can avoid warnings like: warning C4996: 'strncpy': This function or variable may be unsafe. As a special case, Bootstrap uses add_library() instead of qt_internal_add_module(), so _CRT_SECURE_NO_WARNINGS should also be defined in src/tools/bootstrap/CMakeLists.txt. Pick-to: 6.0 Change-Id: Ic82193d177f82785fd84948efa78c49ca8d8db46 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix missing dependencies in *Depends headersJoerg Bornemann2020-11-191-2/+7
| | | | | | | | | | | | | | | In qt_internal_create_module_depends_file we're checking the target property INTERFACE_MODULE_HAS_HEADERS. However, this property is not exported, and in per-repo builds we do not have access to this. As we cannot export INTERFACE_* properties, we export another one, called _qt_module_has_headers. This amends commit 598e873c84e6544aa67495b9b9fb1ff22f98a293. Fixes: QTBUG-88503 Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Enable separate debug info for all target typesCristian Adam2020-11-041-4/+5
| | | | | | | | | | | | | Now all shared libraries and executables will get .debug files on the platforms that support FEATURE_separate_debug_info With the directory property _qt_skip_separate_debug_info certain targets can retain the debug symbols in the binary e.g. lupdate with MinGW 8.1.0 will cause objcopy / strip to fail. Fixes: QTBUG-87015 Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Cleanup module and plugin define situationAlexandru Croitor2020-10-301-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QT.<module>.DEFINES assignment in pri files needs to take into account the module name when computing the define name. This is the MODULE value that qmake specifies. In CMake that would be the value of CONFIG_MODULE_NAME. Previously the value of the define was computed in qt_internal_module_info() without taking into account the module name. While qt_internal_module_info() ended being used also for plugins and other target types, the defines computed by it were meant to be used only for Qt modules. Thus remove the <result>_define assignment from qt_internal_module_info and move its computation directly into qt_internal_add_module, taking into account the value of CONFIG_MODULE_NAME. The only other use of module_define was in qt_internal_add_plugin but that was merely a long overdue copy-paste error, qmake doesn't propagate QT_FOO_LIB defines for plugins. As result, a define special case in testlib is not needed anymore, because the define is now computed properly. Finally, QT_FOO_LIB should not be used while building the Qt module itself, so instead of using PUBLIC_DEFINES option of qt_internal_extend_target, use target_compile_definitions(INTERFACE) directly. Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix deprecation defines not being set properlyAlexandru Croitor2020-10-231-1/+1
| | | | | | | | | Instead of propagating the deprecation wranings, we compiled all code with -Ddeprecations. Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* cmake: Respect NO_PRIVATE_MODULE when generating module pri filesTor Arne Vestbø2020-10-231-1/+7
| | | | | Change-Id: Id5816d6598a0a484c20674f34f6f809e68671e6b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-10 02:10:50 +0000