On lunes, 21 de noviembre de 2016 17:07:08 ART Thiago Macieira wrote: > On segunda-feira, 21 de novembro de 2016 21:33:58 PST Lisandro Damián > Nicanor > Pérez Meyer wrote: > > > I remember in the MeeGo days when building MeeGo with OBS spent an hour > > > on > > > a very beefy machine compiling Qt, with most of the resources in the OBS > > > farm unused because nothing else could be built yet. With Qt 5 and our > > > split packages, this lessens because only qtbase is the bottleneck. > > > > As long as qtbase's private headers do not change. I guess in that case > > one > > who knows exactly what would affect will just rebuild the necessary parts, > > the rest of us need to get all the stuff rebuilt (17 submodules? maybe > > they > > are more right now). > > My point is that there are packages that depend only on qtbase libraries, so > they can start rebuilding as soon as qtbase is done, while the system is > building qtsvg and qtserialport in another node in the farm. And this > scenario was the "rebuild world" case, regardless of whether there were ABI > breakages or not. > > You're right that if you're rebuilding only what needs to be rebuilt, then > an update to qtbase should trigger only rebuilding of packages that > depended on the private API. With the ELF version marker, that should be > easy to detect now.
Just for the record, every time that qtbase's private symbols change we end up requiring a rebuild of almost all the submodules. We might be able to do better with some more hacks, but as we normally require this when we are pushing a new upstream release there is currently not much of a point. > That said, sometimes rebuilding even if there was no dependency on the > private API could result in improvements. For example, every time we add > overloads there's a chance that the new method is faster and will get > selected. Fair point. [snip] > And ELF symbol versioning. That allows both libraries to be loaded into > memory and not interfere with each other, so long as you don't pass data > from one to the other. Indeed, that would really be great. -- Simulations are not data. In God we trust, all the others must supply data. Walter Opyd, "Show Me The Data" IEEE Spectrum's reader's comments, http://www.spectrum.ieee.org/nov04/4004 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
