On Thu, Jul 4, 2019 at 12:36 PM <[email protected]> wrote: > > On Thu, 2019-07-04 at 12:29 -0400, Bruce Ashfield wrote: > > On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie > > <[email protected]> wrote: > > > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote: > > > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang < > > > > [email protected]> > > > > 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.
Aha. > > 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. Understood. I'll think on this for a bit. This has been something that I looked into several times, and didn't come up with anything I really liked. Maybe now is the time to solve the issue :) Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
