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 [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.
Hi, 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? Cheers, Jędrek _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
