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

51 lines
2.1 KiB
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
Break some include cycles in qglobal.h [1/3] Remove qglobal.h include from qcompilerdetection.h, qsystemdetection.h and modulecppexports.h.in Testing locally, the code builds on Linux with precompiled headers disabled/enabled (qt_pch.h includes qglobal.h, so building with PCH enabled isn't useful for testing this) and with/without bootstrap. qrunnable.*: missing includes detected by compiling with -DFEATURE_headersclean=ON. Task-number: QTBUG-106722 Change-Id: I70864dfbf117ffd7fe492eb715a413eb6f209990 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2023-02-12 15:31:11 +00:00
#include <QtCore/qcompilerdetection.h>
#include <QtCore/qtconfigmacros.h> // Q_@module_define_infix@_EXPORT
#include <QtCore/qtdeprecationmarkers.h> // QT_IF_DEPRECATED_SINCE
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
#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
QT_INLINE_SINCE: never inline for static Qt builds Static Qt builds are not covered by BC guarantees, but since all 'libraries' are linked into a single executable, we face in all users of the library the same ODR violation that we faced within the implementation DLL: we can't define the same symbol as inline in some TUs and out-of-line in others. In the past, we decided to always inline in static builds, but that breaks users which, by Hyrum's Law, have come to depend on the non-existent BC guarantees for static Qt builds. By switching to never inline¹ in static builds, we restore BC for such users. The performance issues should be minimal, since LTO will anyway inline whatever it wants, independent on how it was declared. ¹ except when the deprecation point has passed over the Qt version the API was inlined (-disable-deprecated-up-to configure switch). [ChangeLog][QtCore] Restored binary compatibility for static Qt builds broken by the QT_INLINE_SINCE mechanism. Qt still does not guarantee BC for static build configurations otherwise. Fixes: QTBUG-109449 Pick-to: 6.5 6.4 Change-Id: Ie3fa62621b74dc5e9dac301b9882c0e3c3999eaf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-12-15 16:45:56 +00:00
#if !defined(QT_BUILD_@module_define_infix@_LIB) && !defined(QT_STATIC)
Long live QT_INLINE_SINCE! We have now had several requests for inlining previously-exported member functions, but no standard mechanism to effect it. As QT_REMOVED_SINCE has shown, there is great value in having such a standard mechanism, so here is one. With this change, to inline a previously exported (member) function, simply - mark the declaration with QT_<MODULE>_INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE - #include the header into the module's removed_api.cpp Just including the header into removed_api.cpp is enough, so you may want to add a comment: #include "header.h" // uses QT_<MODULE>_INLINE_SINCE The effect is as follows: - A TU in a _different_ library will see an inline declaration, followed by the definition, and so it will see a normal inline function. - A TU in the same library will, however, see a non-inline declaration, to avoid the ODR violation that at least GCC/ld are able to detect. - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also see the definition, which is the same setup as before the change, except in a different TU, and therefore export the member. - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the TU will see no declaration, assuming (correctly), that the definition will be supplied by a different TU. This is, of course, an ODR violation, but not worse than what we do elsewhere, as the definitions differ only between library and user. The function is inline only for the users of the library, not the library itself, which will still see the function as non-inline. If inlining is critical within the library, too, the existing function should call a new inline function, and calls in the same library should be changed to call the new inline function instead. Use the new mechanism to inline the QLocale ctor we intended to inline for 6.3, but couldn't, because we hadn't found the magic incantation, yet. Thiago found it a few weeks later, and this is what this patch is based on. Fixes: QTBUG-100452 Pick-to: 6.4 Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2022-01-31 10:27:49 +00:00
/* outside library → inline decl + defi */
QT_INLINE_SINCE: never inline for static Qt builds Static Qt builds are not covered by BC guarantees, but since all 'libraries' are linked into a single executable, we face in all users of the library the same ODR violation that we faced within the implementation DLL: we can't define the same symbol as inline in some TUs and out-of-line in others. In the past, we decided to always inline in static builds, but that breaks users which, by Hyrum's Law, have come to depend on the non-existent BC guarantees for static Qt builds. By switching to never inline¹ in static builds, we restore BC for such users. The performance issues should be minimal, since LTO will anyway inline whatever it wants, independent on how it was declared. ¹ except when the deprecation point has passed over the Qt version the API was inlined (-disable-deprecated-up-to configure switch). [ChangeLog][QtCore] Restored binary compatibility for static Qt builds broken by the QT_INLINE_SINCE mechanism. Qt still does not guarantee BC for static build configurations otherwise. Fixes: QTBUG-109449 Pick-to: 6.5 6.4 Change-Id: Ie3fa62621b74dc5e9dac301b9882c0e3c3999eaf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-12-15 16:45:56 +00:00
/* static builds treat everything as part of the library, so they never inline */
Long live QT_INLINE_SINCE! We have now had several requests for inlining previously-exported member functions, but no standard mechanism to effect it. As QT_REMOVED_SINCE has shown, there is great value in having such a standard mechanism, so here is one. With this change, to inline a previously exported (member) function, simply - mark the declaration with QT_<MODULE>_INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE - #include the header into the module's removed_api.cpp Just including the header into removed_api.cpp is enough, so you may want to add a comment: #include "header.h" // uses QT_<MODULE>_INLINE_SINCE The effect is as follows: - A TU in a _different_ library will see an inline declaration, followed by the definition, and so it will see a normal inline function. - A TU in the same library will, however, see a non-inline declaration, to avoid the ODR violation that at least GCC/ld are able to detect. - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also see the definition, which is the same setup as before the change, except in a different TU, and therefore export the member. - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the TU will see no declaration, assuming (correctly), that the definition will be supplied by a different TU. This is, of course, an ODR violation, but not worse than what we do elsewhere, as the definitions differ only between library and user. The function is inline only for the users of the library, not the library itself, which will still see the function as non-inline. If inlining is critical within the library, too, the existing function should call a new inline function, and calls in the same library should be changed to call the new inline function instead. Use the new mechanism to inline the QLocale ctor we intended to inline for 6.3, but couldn't, because we hadn't found the magic incantation, yet. Thiago found it a few weeks later, and this is what this patch is based on. Fixes: QTBUG-100452 Pick-to: 6.4 Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2022-01-31 10:27:49 +00:00
# define QT_@module_define_infix@_INLINE_SINCE(major, minor) inline
# define QT_@module_define_infix@_INLINE_IMPL_SINCE(major, minor) 1
#elif defined(QT_@module_define_infix@_BUILD_REMOVED_API)
QT_INLINE_SINCE: take version into account This patch improves the QT_INLINE_SINCE(maj, min) macro to take deprecation version into account. If the specified (maj, min) version is less than or equal to the version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand to "inline", and the out-of-line fallback will be removed from the library. This is achieved by introducing the helper QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro. Fixes: QTBUG-104131 Pick-to: 6.4 Change-Id: I285029dad7b71126072b024a3be6d7b11341996d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
2022-07-19 13:07:06 +00:00
/* inside library, inside removed_api.cpp:
* keep deprecated API → non-inline decl;
* remove deprecated API → inline decl;
* definition is always available */
# define QT_@module_define_infix@_INLINE_SINCE(major, minor) \
QT_IF_DEPRECATED_SINCE(major, minor, inline, /* not inline */)
Long live QT_INLINE_SINCE! We have now had several requests for inlining previously-exported member functions, but no standard mechanism to effect it. As QT_REMOVED_SINCE has shown, there is great value in having such a standard mechanism, so here is one. With this change, to inline a previously exported (member) function, simply - mark the declaration with QT_<MODULE>_INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE - #include the header into the module's removed_api.cpp Just including the header into removed_api.cpp is enough, so you may want to add a comment: #include "header.h" // uses QT_<MODULE>_INLINE_SINCE The effect is as follows: - A TU in a _different_ library will see an inline declaration, followed by the definition, and so it will see a normal inline function. - A TU in the same library will, however, see a non-inline declaration, to avoid the ODR violation that at least GCC/ld are able to detect. - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also see the definition, which is the same setup as before the change, except in a different TU, and therefore export the member. - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the TU will see no declaration, assuming (correctly), that the definition will be supplied by a different TU. This is, of course, an ODR violation, but not worse than what we do elsewhere, as the definitions differ only between library and user. The function is inline only for the users of the library, not the library itself, which will still see the function as non-inline. If inlining is critical within the library, too, the existing function should call a new inline function, and calls in the same library should be changed to call the new inline function instead. Use the new mechanism to inline the QLocale ctor we intended to inline for 6.3, but couldn't, because we hadn't found the magic incantation, yet. Thiago found it a few weeks later, and this is what this patch is based on. Fixes: QTBUG-100452 Pick-to: 6.4 Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2022-01-31 10:27:49 +00:00
# define QT_@module_define_infix@_INLINE_IMPL_SINCE(major, minor) 1
#else
QT_INLINE_SINCE: take version into account This patch improves the QT_INLINE_SINCE(maj, min) macro to take deprecation version into account. If the specified (maj, min) version is less than or equal to the version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand to "inline", and the out-of-line fallback will be removed from the library. This is achieved by introducing the helper QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro. Fixes: QTBUG-104131 Pick-to: 6.4 Change-Id: I285029dad7b71126072b024a3be6d7b11341996d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
2022-07-19 13:07:06 +00:00
/* inside library, outside removed_api.cpp:
* keep deprecated API → non-inline decl, no defi;
* remove deprecated API → inline decl, defi */
# define QT_@module_define_infix@_INLINE_SINCE(major, minor) \
QT_IF_DEPRECATED_SINCE(major, minor, inline, /* not inline */)
# define QT_@module_define_infix@_INLINE_IMPL_SINCE(major, minor) \
QT_IF_DEPRECATED_SINCE(major, minor, 1, 0)
Long live QT_INLINE_SINCE! We have now had several requests for inlining previously-exported member functions, but no standard mechanism to effect it. As QT_REMOVED_SINCE has shown, there is great value in having such a standard mechanism, so here is one. With this change, to inline a previously exported (member) function, simply - mark the declaration with QT_<MODULE>_INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE - #include the header into the module's removed_api.cpp Just including the header into removed_api.cpp is enough, so you may want to add a comment: #include "header.h" // uses QT_<MODULE>_INLINE_SINCE The effect is as follows: - A TU in a _different_ library will see an inline declaration, followed by the definition, and so it will see a normal inline function. - A TU in the same library will, however, see a non-inline declaration, to avoid the ODR violation that at least GCC/ld are able to detect. - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also see the definition, which is the same setup as before the change, except in a different TU, and therefore export the member. - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the TU will see no declaration, assuming (correctly), that the definition will be supplied by a different TU. This is, of course, an ODR violation, but not worse than what we do elsewhere, as the definitions differ only between library and user. The function is inline only for the users of the library, not the library itself, which will still see the function as non-inline. If inlining is critical within the library, too, the existing function should call a new inline function, and calls in the same library should be changed to call the new inline function instead. Use the new mechanism to inline the QLocale ctor we intended to inline for 6.3, but couldn't, because we hadn't found the magic incantation, yet. Thiago found it a few weeks later, and this is what this patch is based on. Fixes: QTBUG-100452 Pick-to: 6.4 Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2022-01-31 10:27:49 +00:00
#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