| Submitter | Laurentiu Palcu |
|---|---|
| Date | Aug. 3, 2012, 8:19 p.m. |
| Message ID | <b41b2c46c9de5d3f63bfa146e23e8974a7a6cebf.1344022584.git.laurentiu.palcu@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/33763/ |
| State | New |
| Headers | show |
Comments
On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> > --- > 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 2. Or better: How about a postinst 'runonce' framework for host/machine? Andreas [1] http://patches.openembedded.org/patch/24179/
On 08/04/2012 02:22 AM, Andreas Müller wrote: > On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu > <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >> --- >> 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. Thanks, Laurentiu > 2. Or better: How about a postinst 'runonce' framework for host/machine? > > Andreas > > [1] http://patches.openembedded.org/patch/24179/ > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote: > > > On 08/04/2012 02:22 AM, Andreas Müller wrote: >> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >> <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >>> --- >>> 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? Andreas > > Thanks, > Laurentiu > >> 2. Or better: How about a postinst 'runonce' framework for host/machine? >> >> Andreas >> >> [1] http://patches.openembedded.org/patch/24179/ >>
Op 3 aug. 2012, om 22:19 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> het volgende geschreven: > 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 <laurentiu.palcu@intel.com> Don't forget to send a patch with PR bumps for all recipes inheriting this class.
On 08/04/2012 12:29 PM, Andreas Müller wrote: > On Sat, Aug 4, 2012 at 9:49 AM, Laurentiu Palcu > <laurentiu.palcu@intel.com> wrote: >> >> >> On 08/04/2012 02:22 AM, Andreas Müller wrote: >>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >>> <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >>>> --- >>>> 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. Thanks, Laurentiu > > Andreas >> >> Thanks, >> Laurentiu >> >>> 2. Or better: How about a postinst 'runonce' framework for host/machine? >>> >>> Andreas >>> >>> [1] http://patches.openembedded.org/patch/24179/ >>> > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> 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 >> <laurentiu.palcu@intel.com> wrote: >>> >>> >>> On 08/04/2012 02:22 AM, Andreas Müller wrote: >>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >>>> <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >>>>> --- >>>>> 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 :)
On Sat, Aug 4, 2012 at 7:14 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: > > Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> 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 >>> <laurentiu.palcu@intel.com> wrote: >>>> >>>> >>>> On 08/04/2012 02:22 AM, Andreas Müller wrote: >>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >>>>> <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >>>>>> --- >>>>>> 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... Andreas
On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller <schnitzeltony@googlemail.com> wrote: > 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 certainly agree with you that it should be run once. However what if you changed something in icons between towo do rootfs runs ? but I would like to know how much build time is it adding to do_rootfs ? sometimes over optimising is bad too.
On Sat, Aug 04, 2012 at 12:51:47PM -0700, Khem Raj wrote: > On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller > <schnitzeltony@googlemail.com> wrote: > > 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 certainly agree with you that it should be run once. However what if > you changed something in icons between towo do rootfs runs ? > but I would like to know how much build time is it adding to do_rootfs ? > sometimes over optimising is bad too. I think Andreas patch does run it once *per* do_rootfs, so not for every package which uses it if there is at least one installed in do_rootfs then it's executed once.
On Sat, Aug 4, 2012 at 9:56 PM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Sat, Aug 04, 2012 at 12:51:47PM -0700, Khem Raj wrote: >> On Sat, Aug 4, 2012 at 12:37 PM, Andreas Müller >> <schnitzeltony@googlemail.com> wrote: >> > 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 certainly agree with you that it should be run once. However what if >> you changed something in icons between towo do rootfs runs ? >> but I would like to know how much build time is it adding to do_rootfs ? >> sometimes over optimising is bad too. Good point I totally forgot (the old approach worked correct for that). I come back to my first post on this: I would like to see some more generic runonce approach... > > I think Andreas patch does run it once *per* do_rootfs, so not for every > package which uses it if there is at least one installed in do_rootfs > then it's executed once. > Andreas
Op 4 aug. 2012, om 21:37 heeft Andreas Müller <schnitzeltony@googlemail.com> het volgende geschreven: > On Sat, Aug 4, 2012 at 7:14 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Op 4 aug. 2012, om 16:01 heeft Laurentiu Palcu <laurentiu.palcu@intel.com> 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 >>>> <laurentiu.palcu@intel.com> wrote: >>>>> >>>>> >>>>> On 08/04/2012 02:22 AM, Andreas Müller wrote: >>>>>> On Fri, Aug 3, 2012 at 10:19 PM, Laurentiu Palcu >>>>>> <laurentiu.palcu@intel.com> 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 <laurentiu.palcu@intel.com> >>>>>>> --- >>>>>>> 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.
Patch
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
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 <laurentiu.palcu@intel.com> --- meta/classes/gtk-icon-cache.bbclass | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)