[OE-core] [PATCH] gtk+: don't provide gtk-update-icon-cache-native

Andreas Müller schnitzeltony at googlemail.com
Wed Mar 27 08:27:32 UTC 2013


On Wed, Mar 27, 2013 at 8:56 AM, Andreas Müller
<schnitzeltony at googlemail.com> wrote:
> On Wed, Mar 27, 2013 at 12:29 AM, Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> On Tue, 2013-03-26 at 15:28 +0100, Andreas Müller wrote:
>>> On Tue, Mar 26, 2013 at 12:48 PM, Richard Purdie
>>> <richard.purdie at linuxfoundation.org> wrote:
>>> > On Tue, 2013-03-26 at 12:40 +0100, Andreas Müller wrote:
>>> >> On Tue, Mar 26, 2013 at 11:32 AM, Burton, Ross <ross.burton at intel.com> wrote:
>>> >> > On 25 March 2013 23:47, Andreas Müller <schnitzeltony at googlemail.com> wrote:
>>> >> >> fixes:
>>> >> >> | ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
>>> >> >> | (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
>>> >> >> | virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
>>> >> >> | This usually means one provides something the other doesn't and should.
>>> >> >
>>> >> > NACK.
>>> >> >
>>> >> > The only way this can happen is if something is depending on
>>> >> > gtk+-native, as everything in oe-core (should) depends on
>>> >> > virtual/gtk-update-icon-cache:
>>> >> >
>>> >> > commit f07515096ea39e267cd3ebeea08cffbba1af07e0
>>> >> > Author: Ross Burton <ross.burton at intel.com>
>>> >> > Date:   Mon Mar 4 12:52:45 2013 +0000
>>> >> >
>>> >> >     default-providers: add default virtual provider for gtk-update-icon-cache
>>> >> >
>>> >> >     Use a virtual provider instead of a hard dependency so that if
>>> >> > gtk+-native is
>>> >> >     required in some configuration, this provider can be changed and then
>>> >> >     gtk+-native and gtk-update-icon-cache-native won't be both built
>>> >> > and conflict in
>>> >> >     the sysroot.
>>> >> >
>>> >> > Presumably some application you've got is explicitly depending on
>>> >> > gtk+-native, probably for the icon cache handling.  It should drop
>>> >> > that build dependency and use the class instead.
>>> >> >
>>> >> > Your fix "works" but will cause file overwrite warnings in sysroot
>>> >> > when you actually do want a gtk+-native, for example if you do want to
>>> >> > build a native gtk+ application or some reason.
>>> >> >
>>> >> > Ross
>>> >> Why do we need two providers which need pinning doing exactly the same?
>>> >
>>> > I'd love to remove gtk+-native.
>>> >
>>> > The icon-cache-native gives about a 5% build speedup as it has a lot
>>> > less dependencies than gtk+-native so it is a good thing. We could fix
>>> > things to coexist however unless there is a good reason to keep gtk
>>> > +-native around, we should switch things over. Things were therefore
>>> > left like this to provide gentle pressure to layers that are still using
>>> > gtk+-native.
>>> >
>>> > If there are valid cases where gtk+-native is still necessary we can
>>> > revisit this but we're not aware of any right now.
>>> >
>>> > Cheers,
>>> >
>>> > Richard
>>> The patch I sent was the attempt to take the first step for
>>> gtk-update-icon-cache-native.
>>> What I see from the tests is that there is no fallout using build time
>>> optimized gtk-update-icon-cache-native based on gtk3. There is no need
>>> for alternate providers here. OK the patch didn't replace
>>> virtual/gtk-update-icon-cache-native by gtk-update-icon-cache-native -
>>> but I could send V2 if the direction is agreed.
>>
>> So to be clear you're saying we don't need gtk+-native for any user
>> you're aware of? Can we remove the BBCLASSEXTEND for native in that
>> case?
>>
>>> If I remember correct there are other gtk-native parts used by the
>>> offline image creation. I don't know what we can replace by optimized
>>> native recipes (based on gtk3).
>>
>> I don't think any of the offline image pieces are using gtk+-native any
>> more...
>>
>> Cheers,
>>
>> Richard
> I will repeat my tests with complete remove of gtk+- native extension.
> If it works I will send a patch - otherwise drop a note.
>
In my environment I found the following references on gtk+-native:

meta-browser: chromium
openembedded-core: packagegroup-toolset-native
openembedded-core: sstate.bbclass
openembedded-core: seperatebuilddir.inc

I have no idea what the oe-core part is for. Since chromium never
built for me: Could the meta-browser friends check which part of
gtk+-native is required - or if replacing gtk+-native by
gtk-update-icon-cache-native is enough?

Andreas




More information about the Openembedded-core mailing list