[OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files

[richard.purdie at linuxfoundation.org]

On Thu, 2019-07-04 at 12:29 -0400, Bruce Ashfield wrote:
> On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote:
> > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang <
> > > zhangzl2013 at 126.com>
> > > wrote:
> > > > Currently, Yocto can not realize the modification of the
> > > > cfg/scc
> > > > files indirectly
> > > > introduced by scc files in custom layers.
> > > > 
> > > > Instead of introducing complicated scc parser code, this patch
> > > > walks though
> > > > FILESEXTRAPATHS and takes all the cfg/scc files into account
> > > > when
> > > > calculating
> > > > checksums.
> > > 
> > > There used to be a bugzilla around for this .. but I can't find
> > > it
> > > now.
> > > 
> > > While the approach isn't wrong, I think it is too heavy, since it
> > > is
> > > looking at *all* the .scc and .cfg files that can be located in
> > > the
> > > search paths, not just the ones that are actually used.
> > 
> > That isn't quite right. With the checksums its important to know if
> > a
> > new file appears at location X, we should reparse as it could
> > change
> > the outcome.
> > 
> > We therefore have to account for files which doesn't exist as much
> > as
> > the ones that do.
> 
> Maybe I'm misunderstanding what you are saying here, but these are
> just sitting around (like unused patch files). They are not on the
> SRC_URI and they are not necessarily used at all. Just because
> someone
> drops a new file in those locations, we should not be re-running the
> meta data task.
> 
> What that routine is currently doing is just wrong.

Agreed, it is.

I'm just saying that this situation isn't as simple as files exist, we
also need to look at which files don't exist, but that would influence
the build if they did.

The patch doesn't do that either!


> > This doesn't work since we need to be able to predict the task hash
> > checksum at parse time. We don't have the kern-tools available then
> > to
> > be able to know which ones it would actually use...
> 
> So there's only python code allowed in those hash routines ? If so,
> what is there is still wrong, and needs to be reworked.

It has to be able to work on the information available to it at parse
time. In reality that does mean python code. There are performance
implications to anything too complex.

Cheers,

Richard