[yocto] Question / issue

[Paul Eggleton]

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.ashfield at 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