From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: sstate_clean() overzealous?
Date: Tue, 04 Oct 2011 11:54:54 +0100 [thread overview]
Message-ID: <1317725702.14671.33.camel@ted> (raw)
In-Reply-To: <1317660469.13337.16.camel@phil-desktop>
On Mon, 2011-10-03 at 17:47 +0100, Phil Blundell wrote:
> The sstate_clean() function in sstate.bbclass is doing (inter alia):
>
> stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
> [...]
> oe.path.remove(stfile + ".*")
> oe.path.remove(stfile + "_setscene" + ".*")
>
> which means that, for tasks which set the stamp-extra-info flag to
> ${MACHINE}, it ends up blowing away the stamps for all machines rather
> than just the current one. The net effect of this seems to be that
> there is no way to have the setscene stamps populated for more than one
> MACHINE at any time, and hence all those tasks get rerun every time you
> change MACHINE even if nothing else has been altered.
>
> Is this behaviour deliberate?
No, its not intended to be wiping out all the different machines.
> It is certainly a little bit annoying but
> I don't understand the internals of sstate well enough to judge what
> exactly that glob is trying to accomplish.
The trouble is we now support a variety of different stamp file formats
depending on what settings you have enabled (and metadata you're using).
Clean can be called from two sources, do_clean, or just before a sstate
controlled task is about to be run. In either case we want to clear out
any previous "state" including any stamp files that might have
represented this task since we're about to invalidate anything they did.
This means wiping out "normal" stamps and any setscene variants of those
stamps. We also want to remove any stamps representing other hashes for
this task since there is no version installed.
If the BasicHash signature generator code is enabled this adds hashes to
the stamp files. This turns the stamps into the form:
<stampfile>.<hash>
or in the case of machine specific tasks:
<stampfile>.<hash>.<machine>
I think we need to teach this clean function about stamp-extra-info and
instead of stfile + ".*", remove stfile + ".*." + stamp-extra-info if
stamp-extra-info is set. That would likely fix the problem you're
seeing.
Cheers,
Richard
next prev parent reply other threads:[~2011-10-04 11:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 16:47 sstate_clean() overzealous? Phil Blundell
2011-10-03 21:11 ` McClintock Matthew-B29882
2011-10-03 21:18 ` Khem Raj
2011-10-03 21:22 ` McClintock Matthew-B29882
2011-10-03 21:24 ` Saul Wold
2011-10-03 21:30 ` McClintock Matthew-B29882
2011-10-03 22:08 ` McClintock Matthew-B29882
2011-10-04 22:19 ` Richard Purdie
2011-10-04 10:54 ` Richard Purdie [this message]
2011-10-04 15:03 ` Phil Blundell
2011-10-04 15:42 ` Richard Purdie
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=1317725702.14671.33.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox