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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
