On 2021-04-07 16:11, Volker Hilsheimer wrote:
On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen <[email protected]> wrote:
On Mittwoch, 7. April 2021 15:18:10 CEST Giuseppe D'Angelo via Development
wrote:
Il 07/04/21 14:56, Sze Howe Koh ha scritto:
Is it acceptable to remove them during Qt 6's lifetime? Or should we
wait till Qt 7?
It's for Qt 7, I'm afraid. We're bound to an API/ABI compatibility
promise. And not marking things _in code_ but only in docs isn't good
enough.
We remove and change private API all the time. If it was declared
deprecated long ago, we could argue it is kind of private in qt6.
'Allan
But declaring an API deprecated requires two things:
* documentation marking it as obsolete
* QT_DEPRECATED_SINCE macro usage to trigger compile time warnings
QMessageBox::buttonText for instance doesn’t have said macro, and is not
inline, so we can’t remove it without de-facto breaking BiC in a material way
(since at least on Windows, the DLL found at runtime has to provide all symbols
that the static import library had at link time, no matter if used or not).
So, what would be not only acceptable but desirable is a bunch of changes that
add QT_DEPRECATED_SINCE to those methods that so far have only been documented
as obsolete. And perhaps even a bit of qdoc tinkering to help us maintain
consistency.
Volker
Hi, not to be a nitpick, but doing that stunt is possible on Windows,
i.e. you can remove obsolete stuff from .dlls without rebuilding any
app, if that obsolete stuff never is called.
You can see what symbols/functions your .exe or .dll needs by doing a
*dumpbin/imports* on it, and normally (unless you're crazy and call
*all* functions in a library) the list of imports will be a subset of
what the static import library provides/offers at link time.
Rgrds Henry
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
