[Development] How to get Qt_5.9.1_PRIVATE_API
Thiago Macieira
thiago.macieira at intel.com
Thu Oct 12 17:07:02 CEST 2017
On quinta-feira, 12 de outubro de 2017 00:27:51 PDT Allan Sandfeld Jensen
wrote:
> On Donnerstag, 12. Oktober 2017 02:47:36 CEST Thiago Macieira wrote:
> > On quarta-feira, 11 de outubro de 2017 13:39:03 PDT Rex Dieter wrote:
> > > The patch's purpose looks appealing, are there "reasons(tm)" it cannot
> > > be
> > > used by default upstream?
> >
> > Yeah: we don't want to.
> >
> > It would make the lives of the developers harder: you'd have to recompile
> > everything the moment that the version was bumped and it would make
> > impossible to mix libraries in order to bisect issues.
>
> Assuming it only applies to private exports, it should only affect libraries
> using private API,
Which is almost all of them. Remember this applies not just to using privates
from QtCore, but any privates between any two libraries, such as QtQml and
QtQuick.
> who should recompile as we do not guarantee ABI for
> those, and in fact have runtime checks in qobject that crashes if the
> private version of a qobjectprivate doesn't match point release of qtbase.
True, but a narrow bisect can find that nothing did change and rebuilding is
possible. For the example of QtQml and QtQuick, it is possible to rebuild just
those two and find the problem, without having to rebuild the whole of qtbase,
qtsvg and qtxmlpatterns, plus whatever else was required to run the test
itself (suppose it used QtLocation).
> Do you think the Suse patch would also break ABI of applications not using
> private API?
No, it only renames the ELF version we apply to privates. It doesn't change
which symbols are marked private.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list