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. 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. > > I can't think of anything that would be worth the major headache that > > breaking BC more often than once every 4 years would cause. And note I'm > > not talking about breaking SC. > > And if this can be coupled with an upstream-made SONAME like 5 to 5abi1... > well, I guess once in 4 years is not that much. 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development