[OE-core] [PATCH] image.bbclass: Ensure IMAGE_FSTYPES is fully evaluated before live/live logic

[Tom Rini]

On Fri, Jun 27, 2014 at 02:40:44PM +0100, Richard Purdie wrote:
> On Thu, 2014-06-26 at 08:27 -0400, Tom Rini wrote:
> > Incase we have overrides applied to IMAGE_FSTYPES we need to make sure
> > that we evaluate it fully before performing the live and vmdk logic
> > checks.
> > 
> > Signed-off-by: Tom Rini <tom.rini at gmail.com>
> > ---
> >  meta/classes/image.bbclass | 9 +++++----
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > index 79de5a2..ccfa1b1 100644
> > --- a/meta/classes/image.bbclass
> > +++ b/meta/classes/image.bbclass
> > @@ -78,10 +78,11 @@ do_rootfs[vardeps] += "BAD_RECOMMENDATIONS NO_RECOMMENDATIONS"
> >  
> >  do_build[depends] += "virtual/kernel:do_deploy"
> >  
> > +EVALED_IMAGE_FSTYPES := "${IMAGE_FSTYPES}"
> >  def build_live(d):
> > -    if base_contains("IMAGE_FSTYPES", "live", "live", "0", d) == "0": # live is not set but hob might set iso or hddimg
> > -        d.setVar('NOISO', base_contains('IMAGE_FSTYPES', "iso", "0", "1", d))
> > -        d.setVar('NOHDD', base_contains('IMAGE_FSTYPES', "hddimg", "0", "1", d))
> > +    if base_contains("EVALED_IMAGE_FSTYPES", "live", "live", "0", d) == "0": # live is not set but hob might set iso or hddimg
> > +        d.setVar('NOISO', base_contains('EVALED_IMAGE_FSTYPES', "iso", "0", "1", d))
> > +        d.setVar('NOHDD', base_contains('EVALED_IMAGE_FSTYPES', "hddimg", "0", "1", d))
> >          if d.getVar('NOISO', True) == "0" or d.getVar('NOHDD', True) == "0":
> >              return "image-live"
> >          return ""
> 
> The trouble is this doesn't add up. 
> 
> EVALED_IMAGE_FSTYPES := "${IMAGE_FSTYPES}"
> 
> basically sets EVALED_... to the expanded value of IMAGE_FSTYPES
> 
> base_contains() also expands the variable its passed.
> 
> I'm a little concerned as to why those two expansions of the same thing
> should result in something different.

Well, they're happening at different parts in the parse.  The vmdk
example is clearer I think since it's not another "big" python function.

> From your later explaination, it would appear the use of the override is
> causing problems but I don't understand how immediate expansion would
> work around that :/.
> 
> So before this merges, more investigation is needed as there is
> something not adding up...

Well, I think the high level answer is that no, we aren't applying
OVERRIDES at the point when we're parsing classes still rather than a
specific task.  Adding an immediate eval at this level does force things
and then we see what we're supposed to.  My gut feeling here is that if
we poke deeply enough at base_contains we'll see that we aren't passing
along the expand flag when we thought we were.

-- 
Tom