> On 7 Apr 2021, at 17:44, Allan Sandfeld Jensen <[email protected]> wrote: > > 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 <[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. > > Yeah, we wouldn't be able to remove private API if that wasn't the case. > > Allan
Right, thanks for correcting. Nevertheless, without compile time warning those methods will still be in use, so we can’t remove them. Cheers, Volker _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
