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>
0d9f4e7526