[Development] Proposal: All Qt modules must use the same version number
olivier at woboq.com
Mon Jun 30 10:06:12 CEST 2014
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 . I would really
> like to avoid adding new stuff to that list, as it is a real PITA.
>  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
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.
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
More information about the Development