Op 4 aug. 2012, om 21:37 heeft Andreas Müller <[email protected]> het volgende geschreven:
> On Sat, Aug 4, 2012 at 7:14 PM, Koen Kooi <[email protected]> wrote: >> >> Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <[email protected]> >> het volgende geschreven: >> >>> >>> >>> On 08/04/2012 12:29 PM, Andreas Müller wrote: >>>> On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On 08/04/2012 02:22 AM, Andreas Müller wrote: >>>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >>>>>> <[email protected]> wrote: >>>>>>> This will improve first boot time because building the icon cache is >>>>>>> done on host, with more processing power than the target. >>>>>>> >>>>>>> Signed-off-by: Laurentiu Palcu <[email protected]> >>>>>>> --- >>>>>>> meta/classes/gtk-icon-cache.bbclass | 10 ++-------- >>>>>>> 1 file changed, 2 insertions(+), 8 deletions(-) >>>>>>> >>>>>>> diff --git a/meta/classes/gtk-icon-cache.bbclass >>>>>>> b/meta/classes/gtk-icon-cache.bbclass >>>>>>> index 01fb2f3..2d82c54 100644 >>>>>>> --- a/meta/classes/gtk-icon-cache.bbclass >>>>>>> +++ b/meta/classes/gtk-icon-cache.bbclass >>>>>>> @@ -1,18 +1,12 @@ >>>>>>> FILES_${PN} += "${datadir}/icons/hicolor" >>>>>>> >>>>>>> -DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == >>>>>>> 'hicolor-icon-theme']}" >>>>>>> +DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == >>>>>>> 'hicolor-icon-theme']} gtk+-native" >>>>>>> >>>>>>> -# This could run on the host as icon cache files are architecture >>>>>>> independent, >>>>>>> -# but there is no gtk-update-icon-cache built natively. >>>>>>> gtk_icon_cache_postinst() { >>>>>>> -if [ "x$D" != "x" ]; then >>>>>>> - exit 1 >>>>>>> -fi >>>>>>> - >>>>>>> # Update the pixbuf loaders in case they haven't been registered yet >>>>>>> GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders >>>>>>> gdk-pixbuf-query-loaders --update-cache >>>>>>> >>>>>>> -for icondir in /usr/share/icons/* ; do >>>>>>> +for icondir in $D/usr/share/icons/* ; do >>>>>>> if [ -d $icondir ] ; then >>>>>>> gtk-update-icon-cache -fqt $icondir >>>>>>> fi >>>>>>> -- >>>>>>> 1.7.9.5 >>>>>>> >>>>>> Long time ago there was a patch introducing gtk-icon-cache to be only >>>>>> run once on the machine [1] and I am still using that. At that time I >>>>>> was asked for a more generic approach. Now I ask: >>>>>> >>>>>> 1. Wouldn't it be better to have gtk-icon-cache run once even on host >>>>> But this is what these patches do. Make gtk-update-icon-cache run on >>>>> host, when the target rootfs is constructed, rather than running it on >>>>> target, at first boot. >>>> As far as I can see gtk-icon-cache is run for each package - how much >>>> extra build time at do_rootfs is to expect? >>> I didn't measure it. But I didn't notice do_roofts task taking a lot >>> more than it took previously. However, host machines these days have >>> lots of MHz under the hood, multiple cores and quite a lot of RAM, >>> compared to target machines. So, I do believe that waiting for some >>> extra tens of seconds at build time is a trade-off we can live with, >>> compared to waiting entire minutes for the target's first boot. >> >> it's about 90 minutes on first boot for beaglebone :) > > And less than 3min on overo with the patches we sent (and my xfce > image is full of gtk-icon-update). Don't misunderstand me: I agree on > doing things like this on host if possible. But for me the main time > waiting on a new image is do_rootfs and I just suggest to think about > having these tasks run only once - but we can do this later or never. > A bit off topic: As far as I can remember there were times when it was > a no-go having gtk-native in oe-core. I hope they are over... I never bought the arguments against gtk-native, so I hope common sense prevails and we can do the icon-cache stuff on the host. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
