On Sunday 29 June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote: > No if it uses private headers. > > I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5 each > time I upload a new point release for this exact problem [0]. I would really > like to avoid adding new stuff to that list, as it is a real PITA. > > [0] Even if API/ABI matches, there seems to be a runtime detection of > different versions of Qt in qobjectprivate. I can really understand why that > check is there, so the best solution is to avoid "third party" stuff to use > private headers. Having a different release schedule will certainly make > any package count as "third party" in my POV.
Totally off topic: I think using private header should be tried to be avoided. In the past, we used private header inside Qt because Qt was not split that much. But one of the goal of modularisation was to allow independent release of different component of Qt. The problem is that we could not get rid of the private header dependencies at the time (too much work). But still now, every module, even new, are using the private headers. Nothing is done to try to prevent it. I think there should be some kind of long term goal to avoid using private headers. We need to find a solution so that one need not to inherit from QObjectPrivate. (There is already QObject::setUserData, but it could be done better i guess) We need also to identify private APIs that could be polished and made public. For some modules such as QtQuick this is probably too hard. But for new modules such as WebEngine or such, it may be possible to avoid dependency on private API. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
