At 2019-07-05 00:42:53, "Bruce Ashfield" <[email protected]> wrote: >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 :)
Thank you Bruce, I will be waiting for your solution. Regards, Zhaolong > >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
