AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ea4d6b987a
qt5base-lts/cmake/modulecppexports.h.in

26 lines
790 B
C
Raw Normal View History

modulecppexports.h.in: re-indent nested preprocessor directives Amends 0d9f4e7526fbf1e072aa3518e4e5313332ee4f18. Task-number: QTBUG-100452 Pick-to: 6.4 6.3 6.2 Change-Id: Iaa6626853a4241f750a6929fc9f604a149c874eb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-06-09 16:24:43 +00:00
// Copyright (C) 2022 The Qt Company Ltd.
Use SPDX license identifiers Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-10 10:06:48 +00:00
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR LGPL-3.0-only OR GPL-2.0-only OR GPL-3.0-only
Implement generating of a module cpp export header 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>
2021-06-22 15:37:55 +00:00
Implement generating of private cpp exports 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>
2021-07-30 15:51:07 +00:00
#ifndef @header_base_name_upper@_H
#define @header_base_name_upper@_H
Implement generating of a module cpp export header 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>
2021-06-22 15:37:55 +00:00
#include <QtCore/qglobal.h>
#if defined(QT_SHARED) || !defined(QT_STATIC)
# if defined(QT_BUILD_@module_define_infix@_LIB)
# define Q_@module_define_infix@_EXPORT Q_DECL_EXPORT
# else
# define Q_@module_define_infix@_EXPORT Q_DECL_IMPORT
# endif
#else
# define Q_@module_define_infix@_EXPORT
#endif
Make one QT_REMOVED_SINCE/QT_BUILD_REMOVED_API per module A single global QT_REMOVED_SINCE will start hurting us once more modules downstream of QtCore start using the mechanism. With every use of feature, the set of code that needs to compile under QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in situations where overloading the new and the old function don't work in general, this means all code included by any removed_api.cpp needs to be very carefully written to ensure that any calls to the overload set formed by the combination of old and new function(s) don't create ambiguities. Likewise, the set of APIs that change semantics under QT_BUILD_REMOVED_API also increases. At some point, the combination of removed_api.cpp including almost every module header and almost every header exposing source-incompatibilities when included in removed_api.cpp will make maintenance a headache. By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module (QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export macros using CMake, we limit the scope of this problem to the module using the feature. Downstream modules (say, QtWidgets) will now see the QtCore API like every other user, even in the widgets/compat/removed_api.cpp TU. Pick-to: 6.3 Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-01-31 10:10:26 +00:00
#ifdef QT_@module_define_infix@_BUILD_REMOVED_API
modulecppexports.h.in: re-indent nested preprocessor directives Amends 0d9f4e7526fbf1e072aa3518e4e5313332ee4f18. Task-number: QTBUG-100452 Pick-to: 6.4 6.3 6.2 Change-Id: Iaa6626853a4241f750a6929fc9f604a149c874eb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-06-09 16:24:43 +00:00
# define QT_@module_define_infix@_REMOVED_SINCE(major, minor) QT_DEPRECATED_SINCE(major, minor)
Make one QT_REMOVED_SINCE/QT_BUILD_REMOVED_API per module A single global QT_REMOVED_SINCE will start hurting us once more modules downstream of QtCore start using the mechanism. With every use of feature, the set of code that needs to compile under QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in situations where overloading the new and the old function don't work in general, this means all code included by any removed_api.cpp needs to be very carefully written to ensure that any calls to the overload set formed by the combination of old and new function(s) don't create ambiguities. Likewise, the set of APIs that change semantics under QT_BUILD_REMOVED_API also increases. At some point, the combination of removed_api.cpp including almost every module header and almost every header exposing source-incompatibilities when included in removed_api.cpp will make maintenance a headache. By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module (QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export macros using CMake, we limit the scope of this problem to the module using the feature. Downstream modules (say, QtWidgets) will now see the QtCore API like every other user, even in the widgets/compat/removed_api.cpp TU. Pick-to: 6.3 Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-01-31 10:10:26 +00:00
#else
modulecppexports.h.in: re-indent nested preprocessor directives Amends 0d9f4e7526fbf1e072aa3518e4e5313332ee4f18. Task-number: QTBUG-100452 Pick-to: 6.4 6.3 6.2 Change-Id: Iaa6626853a4241f750a6929fc9f604a149c874eb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-06-09 16:24:43 +00:00
# define QT_@module_define_infix@_REMOVED_SINCE(major, minor) 0
Make one QT_REMOVED_SINCE/QT_BUILD_REMOVED_API per module A single global QT_REMOVED_SINCE will start hurting us once more modules downstream of QtCore start using the mechanism. With every use of feature, the set of code that needs to compile under QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in situations where overloading the new and the old function don't work in general, this means all code included by any removed_api.cpp needs to be very carefully written to ensure that any calls to the overload set formed by the combination of old and new function(s) don't create ambiguities. Likewise, the set of APIs that change semantics under QT_BUILD_REMOVED_API also increases. At some point, the combination of removed_api.cpp including almost every module header and almost every header exposing source-incompatibilities when included in removed_api.cpp will make maintenance a headache. By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module (QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export macros using CMake, we limit the scope of this problem to the module using the feature. Downstream modules (say, QtWidgets) will now see the QtCore API like every other user, even in the widgets/compat/removed_api.cpp TU. Pick-to: 6.3 Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-01-31 10:10:26 +00:00
#endif
Implement generating of private cpp exports 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>
2021-07-30 15:51:07 +00:00
#endif // @header_base_name_upper@_H
Reference in New Issue Copy Permalink