[OE-core] [PATCH] utils.bbclass: skip empty paths when handling FILESEXTRAPATHS

[Paul Eggleton]

On Friday 19 August 2011 23:16:53 Martin Jansa wrote:
> On Fri, Aug 19, 2011 at 03:11:08PM -0700, Chris Larson wrote:
> > On Fri, Aug 19, 2011 at 5:16 AM,  <martin.jansa at gmail.com> wrote:
> > > From: Martin Jansa <Martin.Jansa at gmail.com>
> > > 
> > > * if there is multiple .bbappend files with FILESEXTRAPATHS_prepend :=
> > > "/:" then the one parsed last is causing trailing ':' and that's
> > > causing empty element in path = extrapaths.split(:) + path
> > > * it's hard to keep all .bbappends from foreign layers to follow this
> > > rule, so it's better to be able to handle trailing ':'
> > > 
> > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > ---
> > >  meta/classes/utils.bbclass |    5 +++--
> > >  1 files changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
> > > index 56abdd8..3c2e342 100644
> > > --- a/meta/classes/utils.bbclass
> > > +++ b/meta/classes/utils.bbclass
> > > @@ -338,8 +338,9 @@ def base_set_filespath(path, d):
> > >        # The ":" ensures we have an 'empty' override
> > >        overrides = (bb.data.getVar("OVERRIDES", d, 1) or "") + ":"
> > >        for p in path:
> > > -               for o in overrides.split(":"):
> > > -                       filespath.append(os.path.join(p, o))
> > > +               if p != "":
> > > +                       for o in overrides.split(":"):
> > > +                               filespath.append(os.path.join(p, o))
> > 
> > You shouldn't use 'p != "":'. Instead, use the fact that the empty
> > string is false in boolean context.  'if p:'.
> > 
> > Of course, you could also use filter. path = filter(None, path) --
> > filtering an iterable with a function of None results in it dropping
> > all false values. But then, there's a tendency nowadays to avoid
> > map/filter/etc, so that's probably not best :)
> 
> does it apply to all != "" in utils.bbclass? because I've used it just
> because it's at least 3 times in this file already.. so to be consistent
> with the rest..

FWIW I agree with Martin; I wouldn't hold back the patch just for this reason 
- it's not incorrect code, it's consistent with the rest of the file, and we 
can easily clean these up later.

Acked-by: Paul Eggleton <paul.eggleton at linux.intel.com>

- Paul
-- 

Paul Eggleton
Intel Open Source Technology Centre