summaryrefslogtreecommitdiffstats
path: root/cmake/QtModuleHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix typosKai Köhne2022-06-131-1/+1
| | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: set correct COMPILE_PDB_NAME for static librariesLi Xinwei2022-05-201-1/+2
| | | | | | | | | | | | | | | Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add qpa include directory to the return values of qt_internal_module_infoAlexey Edelev2022-05-021-1/+16
| | | | | Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Work around build rpath issue when CMAKE_STAGING_PREFIX is setAlexandru Croitor2022-04-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake has logic to rewrite build rpaths that contain CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX. This breaks running executables from the build directory, because their build rpath will point to a location where the libraries might not exist yet (we didn't install Qt yet). Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so that CMake does not do the rewriting anymore. CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not function scope, which is why qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro that is called from within each Qt internal function that creates a target. The workaround can be disabled by configuring with -DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON The downside of this workaround is that it breaks per-subdirectory install rules like 'ninja src/gui/install'. Regular global installation like 'ninja install' works fine. This is similar to what we do for tests in qt_set_up_fake_standalone_tests_install_prefix() introduced by 20292250d44e08437306096e9096fc655cc9fb8b The reason it's not as good for other target types is because in contrast to tests, we do want to install them. In case if someone does call `ninja src/gui/install' they will most likely get a permission error, telling them it's not possible to install into /qt_fake_staging_prefix/ check_qt_internal_apply_staging_prefix_build_rpath_workaround Fixes: QTBUG-102592 Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Mitigate moc not finding correct headers in framework buildsAlexandru Croitor2022-03-181-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CMake generates compilation rules, it extracts the values from INTERFACE_INCLUDE_DIRECTORIES and checks if any of the values are framework paths. If they are, instead of adding an -I ./lib/My.framework to the compilation rules, it adds -iframework ./lib or -F ./lib. The same transformation does not happen when AUTOMOC passes include paths to moc, nor during a headersclean check. The values there are passed verbatim, with an -I prepended. This causes issues when the include file name is the same as the framework name. E.g. #include <QtQml> + -I ./lib/QtQml.framework because moc then ends up silently including the shared library ./lib/QtQml.framework/QtQml instead of the header ./lib/QtQml.framework/Headers/QtQml This can lead to a variety of silent issues during moc generation, because all the definitions of QtQml will be missing. Unfortunately, there does not seem to be a clean way to fix this in the build system due to CMake semantics. See https://gitlab.kitware.com/cmake/cmake/-/issues/23337 for details. We can mitigate the issue by ensuring that -I ./lib/QtQml.framework/Headers comes before -I ./lib/QtQml.framework by manipulating the order of values in INTERFACE_INCLUDE_DIRECTORIES. We might want to consider implementing an additional mitigation in AUTOMOC, so that it filters out include paths like -I ./lib/QtQml.framework, thus ensuring that a newer CMake version will not exhibit the same issue when used with an older Qt. We could consider doing the same in moc. The advantage of doing it in moc is that that moc will consider fewer invalid include paths when searching for headers. Amends 4b2de41b13eb71c0ce841ef357768a3913b49810 Amends d7efb2a419a88c8f512b98194c8f7bc81dbe942b Pick-to: 6.2 6.3 Fixes: QTBUG-89545 Fixes: QTBUG-101718 Fixes: QTBUG-101775 Change-Id: Ib2c25b5744bd2b5c9c83813bb04ad88c0179f6ec Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* build system: support module local definitionsFabian Kosmale2022-03-111-0/+2
| | | | | | | | | | | | | | | | | | | This introduces a new helper function, qt_internal_add_repo_local_defines and makes use of it in qt_internal_add_{module,test,executable,benchmark,plugin}. That function checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the defines listed in there will be aded to all targets passed to the functions mentioned above. The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set in the repository local .cmake.conf. This allows e.g. opting in to source incompatible changes in leaf modules (as long as those are guarded by some define). Pick-to: 6.2 6.3 Fixes: QTBUG-101640 Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable -mno-direct-extern-access and ELF protected visibilityThiago Macieira2022-03-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -mno-direct-extern-access tells the compiler and linker that references to symbols outside this ELF module mustn't be direct and must instead always go through the GOT or PLT (the PLT can additionally be disabled with -fno-plt). The ELF protected visibility tells the compiler and linker that this symbol is present in the dynamic symbol table as an export, but it cannot be interposed by another ELF module. This option is required for user code to link properly to Qt, otherwise they will get linker errors (assuming GNU binutils >= 2.39) or runtime failures (glibc >= 2.35). Both versions of glibc and binutils are older than GCC 12, so it's a safe assumption they are in use and downgrading the toolchain or libc is not supported. Adding this option to the compilation is assured for CMake and qmake-based projects. For example, all accessess to QCoreApplication::self in QtCore, after this change and with GCC 12 are relocation-free and direct: 000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>: 13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self> 13ebf8: setne %al 13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]> 13ec01: ret Meanwhile, accesses to the same variable in other modules are indirect via the GOT: 66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6> 66657: cmpq $0x0,(%rax) This replaces the -Bsymbolic and -Bsymbolic-functions (broken) functionality that Qt has been using or attempting to use since ~2006. See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128 Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake build: generate pkgconfig for public modulesMartin Reboredo2022-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix exclusion of QtFoo in QtBarDepends for 3rd party libsAlexandru Croitor2022-02-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When configuring a static Qt with the -qt-zlib option and the build system creates a 3rd party header module QtZlib, syncqt does not generate a QtZlib header file that would include all its public headers. Then when the QtSvgDepends header is generated, it would add an #include <QtZlib> which would break compilation of the QtSvg PCH file (which compiles QtSvgDepends). We have logic to exclude addition of headers from regular 3rd party static libraries, but not header only 3rd party libraries. Adjust the code to handle header-only 3rd party libraries, as well as make sure it works across repos by exporting the relevant properties. As a drive-by, also rename and export some other informational properties. Amends af00402d6446c0f8f085a2a482fc83c4318aa457 Amends 6fdeaea24f9035ad53ba2548a9467b3264cf01ad Amends be2745e4788cecb0d3122081e3328e4b66923609 Pick-to: 6.2 6.3 Change-Id: I087f50b193dd845e4a5ec906e8851d63122faf80 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Install 3rdparty headers for static buildsMichal Klocek2022-02-191-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | For static builds we need 3rdparty headers to be installed. Leaf modules like qtwebengine needs 3rdparty libs and header for zlib, freetype, harfbuzz, png, jpeg. Without those the Chromium bundled versions are used, however it might end up badly if qt has already bundled one. Introduce new header only modules with additional arguments for qt_internal_add_module: * EXTERNAL_HEADERS to pick exactly which headers are public * EXTERNAL_HEADERS_DIR to include whole directory preserving the files directory structure Fix qtsync so it keep directory structure for all non-qt modules when syncing headers and do not generate warnings for headers files. Task-number: QTBUG-87154 Task-number: QTBUG-88614 Change-Id: If1c27bf8608791cd4e0a21839d6316a445a96e9f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 06:23:36 +0000