On Fri, 2015-07-17 at 13:01 +0100, Richard Purdie wrote:
> On Thu, 2015-07-16 at 23:22 +0100, Burton, Ross wrote:
> >
> > On 16 July 2015 at 22:29, Martin Jansa <martin.ja...@gmail.com> wrote:
> > ERROR: Nothing PROVIDES 'gtk+-native' (but
> >
> > virtual:native:/home/jenkins/oe/world/shr-core/meta-openembedded/meta-oe/recipes-extended/libwmf/libwmf_0.2.8.4.bb
> > DEPENDS on or otherwise requires it). Close matches:
> >
> > So libwmf does this:
> >
> > DEPENDS_virtclass-native = "freetype-native libpng-native jpeg-native"
> > DEPENDS = "freetype libpng jpeg expat gtk+"
> >
> > Interestingly changing this to _class-native fixes the problem.
>
> Strangely, the answer as to what might be wrong occurred to me in the
> shower this morning. We should try changing:
>
> native.bbclass: e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES",
> False) + ":virtclass-native")
>
> to
>
> e.data.setVar("FOO", "virtclass-native")
> e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":${FOO}")
>
> and if that makes things work, its the override caching mechanism that
> is bust for direct changes to OVERRIDES which don't use variable
> indirection (most do).
>
> If that is the case, a fix shouldn't be hard.
Its actually much simpler than this. DEPENDS is evaluated in
native_virtclass_handler(e):28 [map_dependencies] which is before
virtclass-native is added to OVERRIDES. The act of setting the DEPENDS
variable wipes out any other overrides which may not have been applied
to that point. The fixes are:
a) Move the virtclass-native addition to OVERRIDES to earlier in the
function
b) Change meta-oe use of virtclass -> class
c) Drop use of virtclass-native and virtclass-nativesdk entirely (only
multilib really makes sense now).
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
