On Monday 12 May 2014 07:03:55 Bruce Ashfield wrote: > On 14-05-12 01:56 AM, Paul McGougan wrote: > > From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] > > > >>> Secondly, (and this is our main issue) I have found that by adding the > >>> do_install_append function, even if it is completely empty, whenever I > >>> try to bitbake anything that depends on the kernel, that bitbake always > >>> re-runs the kernel install stage, even when there have been no changes. > >>> Literally I can run a bitbake, then run the same bitbake command again, > >>> and both times the kernel install stage gets run (this is a problem > >>> because it takes a long time to run). It appears to be happening because > >>> the stampfile is not found every time (the hash appears to be wrong). > >>> Is this a bug? Is there a fix or work-around for this problem? > >> > >> In this front, I'm not the best reference. Checking the sstate signature > >> might help, it should show which variables are being used .. and possibly > >> invalidating the signature, triggering the steps to run again. > > > > Thanks Bruce. > > > > Just for reference of anyone else who runs into a similar issue our issue > > was: 1. The do_install_append function was not *really* empty, the > > content of it was commented out. > > 2. The dependency parser when parsing recipes not only looks for content > > changes, but for also for changes to the values of referenced variables, > > and unfortunately it still performs variable-value substitution in > > commented-out code. In our case, we had the variable $DATETIME in there > > (but commented out), this caused the dependency checker to substitute in > > the current value for DATETIME which of course changed on each run. > > Aha. That's what I thought it might be (and what I've been hit by > before in the past), sstate signature checking showed the variable > in these other cases .. so I thought I'd suggest it. > > Glad to hear you have a working solution. > > > The fix was to add: > > do_install[vardepsexclude] += "DATETIME"
Er, if DATETIME is in the dependencies for this task and that is a bug in the core recipe, we should fix it in the core. The question is how is it getting in there? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto