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.

Cheers,

Bruce


The fix was to add:
do_install[vardepsexclude] += "DATETIME"

Regards,
Paul McGougan

Confidentiality Notice:  This message (including attachments) is a private 
communication solely for use of the intended recipient(s).
If you are not the intended recipient(s) or believe you received this message 
in error, notify the sender immediately and then delete this
message.  Any other use, retention, dissemination or copying is prohibited and 
may be a violation of law, including the Electronic
Communication Privacy Act of 1986."


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to