On Saturday 02 of January 2010, Dirk Müller wrote:
On Friday 25 December 2009, Lubos Lunak wrote:
Another problem was a long KDE:Qt rebuild, and the aggregate in KKFD seems to stop being blocked only after all of KDE:Qt has been rebuilt (even packages that are actually not aggregated, for whatever reason).
The usual fix when you don't want to wait is: disable the aggregate temporarily. Therefore I don't consider optimisations of Qt project (!) rebuild time as extremely important.
I see, I didn't know that. That would have made this a lot simpler.
The most interesting problem in KDE:Qt is that the Qt libraries themselves, including WebKit, get rebuilt in every libqt4* package.
yep.
Since things like qt- declarative had a dependency on libqt4-devel-doc, they needed to wait for double Qt rebuild.
Thats bad indeed.
However, most of the libqt4-devel-doc dependencies were unnecessary, so I have removed them.
which? I only see this change:
I meant other packages in KDE:Qt depending on libqt4-devel-doc.
Changes in KDE:Qt should be moving the help generation tools from libqt4-devel-doc to libqt4-devel, where they IMO belong anyway, if apps need them for building documentation during their build.
I was told that they're also needed during runtime. I don't want to pull in libqt4-devel for normal runtime usage. If that is incorrect, then the move would be a good idea indeed. I guess some grepping of source code is in order to verify that the tools are not called during runtime.
I don't see any relevant reference to the tools from the source itself, only docs and makefiles. So I think it's ok to move them (and even if not, they could be made into a libqt4-devel subpackage that both the packages would depend on).
Second change should be making sure that Qt libs and WebKit are built only once. The trick is to install libqt4- devel (and libQtWebKit-devel) and symlinking them to the build dir's bin/ and lib/. It seems to work just fine. I additionally split off libqt4-webkit, in order to have libqt4-devel ready sooner for some further packages that don't require WebKit, although I'm not entirely sure it's worth it (most stuff requires WebKit anyway, and the aggregate blocks KKFD anyway).
I don't think splitting off webkit saves significant time, thats why we changed this for 4.6, it used to be built seperately. building of Qt is complex enough, the fewer spec files the better.
Ok, I won't add it then.
(it's mostly just kde4_no_enable_final(<whatever>) in the subdir's CMakeLists.txt or just disabling it altogether for the package). Do you think it'd be worth it? We used to build KDE3 this way too.
yeah, and we always had to fix it (wrong #defines, static's that globber each other and other things introducing weird bugs), and of course, upstream always blamed our packages rather than the actual reason for the bug.
I occassionally used it with KDE3 and I don't remember it breaking often. And now it was only like 10 breakages, and that was probably after nobody caring about it for 2 years (since cmake's dependency handling makes final mode really suck for development). And I wasn't suggesting to build everything that way, just the 3 basic packages.
I'd rather not use it unless it has a *significant* effect on either runtime performance or compile time.
It reduces kdelibs4 from 1:20 to 0:20 and kdebase4-workspace from 1:00 to 0:20 (and that's including the buildroot setup, a local rebuild with icecream could probably do it in 5 minutes if I fixed the meinproc OOM problem). But ok, I won't enable it then, but I think I will still add it to the .spec at least with a %define.
With all these changes, the final table should look like this: libqt4 0:30 (+0:30) -> libqt4-webkit 1:00 (+0:30) -> libqt4-devel-doc 1:20 (+0:20)
so 30 minute improvement here. I think thats significant. I'm fine with adding your symlink trick to the libqt4-devel-doc.spec.in.
in general, all these "black magic tricks" appears to be fragile, as it usually breaks in some way with the next Qt update. I had several of them, and got rid of them one after the other again.
I don't consider it fragile. The Qt symlinking should be perfectly fine, there are even Makefile targets for just rebuilding parts of Qt without any of their dependencies. Do you want the changes also somewhere else other than KDE:Qt?
This is usually wasting me a lot of time (in the range of hours or days), which I consider worse for my productivity then having to wait 30 minutes for a build to finish (during which I can do something else, like enjoying frozen bubble ;) ).
-- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org