[Development] Proposal: All Qt modules must use the same version number
jedrzej.nowacki at digia.com
Mon Jun 30 11:10:28 CEST 2014
On Monday 30 of June 2014 10:06:12 Olivier Goffart wrote:
> 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
> 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.
As I agree in principle I do not think it is feasible in all cases. There
are few problems:
1. Lack of public api
1.1 We have private api that could be polished and promoted to public, that
could be done of course it is a bit of effort but it make sense.
1.2 Private api that make sense only to an internal use-case, does it make
sense to generalize it and potentially make everything more complex,
especially in context of long term BC?
2 Performance, public api is generally slower then a private one, because of
inline'ing, type checks, range checks and so on.
What about creating an intermodule api, which would stay private from a user
point of view. We can agree on some rules, like for example not removing
symbols between patch releases, having some test coverage?
More information about the Development