On Mittwoch, 7. April 2021 16:53:16 CEST Henry Skoglund wrote: > On 2021-04-07 16:11, Volker Hilsheimer wrote: > >> On 7 Apr 2021, at 15:55, Allan Sandfeld Jensen <k...@carewolf.com> 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.
Yeah, we wouldn't be able to remove private API if that wasn't the case. Allan _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
