Re: [PATCH] bitbake warning fix: No bb files matched BBFILE_PATTERN_packageName

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2017-10-06 at 13:37 -0700, Andre McCurdy wrote:
> > 
> > On Tue, Sep 27, 2016 at 11:54 AM, Mounesh Sutar <mounesh.sutar@gmai
> > l.com>
> > > 
> > > 
> > > bitbake is parsing all recipe files, against layers
> > > BBFILE_PATTERN for
> > > warning message display.
> > > In case of sublayer with lower/equal priority, then all
> > > sublayer's
> > > patterns are not being
> > > considered for pattern match. While checking recipe file against
> > > matching
> > > pattern,
> > > the first matching pattern is accepted and added to matched list,
> > > while
> > > remaning PATTERNs are
> > > not being considered. With this, the recipes are being neglected
> > > from
> > > PATTERN match.
> > > This fix let's parser run through all the layers PATTERNs and on
> > > matching
> > > added to match list.
> > > 
> > > Upstream-Status: Submitted [bitbake-devel@lists.openembedded.org]
> > > 
> > > Signed-off-by: Mounesh Sutar <mounesh_sutar@mentor.com>
> > > ---
> > >  bitbake/lib/bb/cooker.py |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
> > > index 4df8881..5fde995 100644
> > > --- a/bitbake/lib/bb/cooker.py
> > > +++ b/bitbake/lib/bb/cooker.py
> > > @@ -1705,7 +1705,7 @@ class CookerCollectFiles(object):
> > >                  if matched != None:
> > >                      if not regex in matched:
> > >                          matched.add(regex)
> > > -                return pri
> > > +                        return pri
> > >          return 0
> > > 
> > >      def get_bbfiles(self):
> > > --
> Resurrecting an old thread as it's been pointed out to me that this
> patch fixes the issue I raised a while ago on the oe-core list:
> 
>   http://lists.openembedded.org/pipermail/openembedded-core/2016-July
> /123466.html
> 
> Are there any problems or concerns with this change?

I had to go and look at this again but yes, there are problems with the
patch:

a) If matched = None, the function never returns a priority after this 
   change.
b) Currently the first match is returned and also used in parallel for 
   the priority calculation. After the patch, the priority used would 
   be the last match found. The patch therefore reverses priority 
   assignments for layers.

There is a definite problem here but the patch simply moves the
goalposts, it doesn't actually fix it. It breaks the current behaviour
too.

Cheers,

Richard