> On Sept. 13, 2015, 9:27 p.m., David Faure wrote: > > modules/ECMInstallIcons.cmake, line 187 > > <https://git.reviewboard.kde.org/r/125192/diff/1/?file=402974#file402974line187> > > > > Olivier, I was wrong! You can remove the recursive mtime check from Qt, > > if the rule is always that any icon installation must touch the toplevel > > dir. Which clearly we were doing already. Sorry for the wrong advice on my > > part. > > Olivier Goffart wrote: > David: but does the package manager that contains icons will touch the > theme directory? > > David Faure wrote: > Ah, good question. No idea though. That's a question for > [email protected], where the packagers will be able to answer you. > > Maciej Mrozowski wrote: > Icon cache is cretaed at package install phase by package manager. cmake > install (where you invoke gtk-update-icon-cache) is source install phase. > Source install phase happens in sandboxed environment most of the time so > runnig gtk update icon cache will just work for kdebuild and local > installations. For distro packagers this will be a command to sed-out from > CMakeLists. > > Maciej Mrozowski wrote: > Small update. Icon cache is movable (does not contain absolute paths) so > icon cache will work when copied from package installation image to target > filesystem. Still generating it in buildsystem is stepping a bit too far into > packager area. With my Gentoo hat on. Worth asking jriddel what he thinks. > > Volker Krause wrote: > This is purely meant for developer builds, not distros. There this is > better done in post install hooks indeed. The DESTDIR check around this > should disable this for normal distro builds, same as we do already for e.g. > updating the mime database. > > David Faure wrote: > And this is all somewhat besides the point. The question wasn't > "can/should packages run gtk-update-icon-cache in the future" (the answer is > yes). > > The question is... when you install some package that was made in the > last 8 years and that isn't about a GTK application, let's say firefox, > libreoffice or whatever else, > if the package contains icons, does the package manager touch the > toplevel icon theme directory or not. > If not, then we are going to miss the new icons. But then again, I > suppose GTK would miss them too..... So I guess packages do update the dir > (or even run the gtk tool).
Sorry David, I missed that this question was still open. Yes, this can be messed up in packaging. The distros we looked at so far either run gtk-update-icon-cache in post install hooks correctly (ie. same way as update-mime-db, whenever a package installs stuff into the shared locations), or not at all. Compromising performance for a hypothetical distro with broken packaging looks like an unnecessary pessimisation IMHO. - Volker ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125192/#review85334 ----------------------------------------------------------- On Sept. 12, 2015, 12:23 p.m., Volker Krause wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125192/ > ----------------------------------------------------------- > > (Updated Sept. 12, 2015, 12:23 p.m.) > > > Review request for Extra Cmake Modules and Olivier Goffart. > > > Repository: extra-cmake-modules > > > Description > ------- > > Despite the name, Qt is also using this, and it considerably speeds up > icon lookup. > > > Diffs > ----- > > modules/ECMInstallIcons.cmake 79dc5150e8a966db2a9fdd39cbd5ce8c2f842e18 > > Diff: https://git.reviewboard.kde.org/r/125192/diff/ > > > Testing > ------- > > Built and installed kdepim, cache files are generated in the expected places. > > > Thanks, > > Volker Krause > >
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
