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).
Yes, thats a strange limitation of the buildservice. as the aggregate is not actually necessary (as it also builds against the project, and this method doesn't block) for correct building, it is only there to make the repo self- contained (so that not KDE:Qt and KKFD have to be added for older repos). 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.
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: Name: libqt4-devel-doc BuildRequires: cups-devel freeglut-devel libjpeg-devel libpng-devel -BuildRequires: libqt4-devel alsa-devel gtk2-devel sqlite3-devel +BuildRequires: libqt4-devel alsa-devel gtk2-devel sqlite3-devel libQtWebKit- devel %if 0%{?suse_version} > 1020
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.
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.
(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'd rather not use it unless it has a *significant* effect on either runtime performance or compile time.
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. 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 ;) ). Greetings, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org