All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Nyström" <david.c.nystrom@gmail.com>
To: Paul McGougan <PMcGougan@topcon.com>,
	 "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Question / issue
Date: Mon, 12 May 2014 20:43:03 +0200	[thread overview]
Message-ID: <53711637.7070105@gmail.com> (raw)
In-Reply-To: <C7589FE7B0DE58488F2B9BF79840E9D90D66F94E@ADL-EXCHMBX1.TOPCON.com>


On 2014-05-12 07:56, Paul McGougan wrote:
> From: Bruce Ashfield [mailto:bruce.ashfield@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.

To me, Thats sound like a bug in the dependency parser.
It should not parse for changes in comments, i.e. in this case 
do_install_append comments.

Or perhaps in variable expansion, which could be avoided in commented 
sections.

Br,
David



  parent reply	other threads:[~2014-05-12 19:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09  5:14 Question / issue Paul McGougan
2014-05-09 14:44 ` Bruce Ashfield
2014-05-12  5:56   ` Paul McGougan
2014-05-12 11:03     ` Bruce Ashfield
2014-05-12 11:10       ` Paul Eggleton
2014-05-12 23:29         ` Paul McGougan
2014-05-12 18:43     ` David Nyström [this message]
2014-05-12 23:31       ` Paul McGougan
2014-05-13  7:10         ` Richard Purdie
2014-05-19 13:41   ` Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53711637.7070105@gmail.com \
    --to=david.c.nystrom@gmail.com \
    --cc=PMcGougan@topcon.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.