From: Patrick Ohly <patrick.ohly@intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: paul.eggleton@intel.com, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] buildhistory.bbclass: remove out-dated information on request
Date: Mon, 08 Feb 2016 13:35:20 +0100 [thread overview]
Message-ID: <1454934920.8641.4.camel@intel.com> (raw)
In-Reply-To: <1454921553.16142.42.camel@linuxfoundation.org>
On Mon, 2016-02-08 at 08:52 +0000, Richard Purdie wrote:
> On Mon, 2016-02-08 at 07:56 +0100, Patrick Ohly wrote:
> > buildhistory.bbclass by design is incremental: each build adds or
> > updates information. Information is never removed.
> >
> > Sometimes it can be useful to reduce the information only to those
> > recipes that were build during a specific bitbake invocation, for
> > example when the invocation does a full world build.
> >
> > This is now possible by invoking bitbake with:
> > BB_ENV_EXTRAWHITE=BUILDHISTORY_REMOVE_OLD
> > BUILDHISTORY_REMOVE_OLD=1 bitbake
> >
> > In this mode, buildhistory.bbclass first moves all existing
> > information into a temporary directory called "old" inside the build
> > history directory. There the information is used for the "version
> > going backwards QA check". Then when the build is complete and before
> > (potentially) committing to git, the temporary directory gets
> > deleted.
> >
> > Because information that has not changed during the build will be
> > reconstructed, a git log will then only show real updates, additions
> > and removals.
> >
> > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
>
> The implicit assumption here is that you'd only every build large
> targets like "world". A "bitbake bash" isn't really going to do what
> you'd expect/want.
Yes, I know. I think the "reduce the information only to those recipes
that were built during a specific bitbake invocation" is a bit clearer
about that than the last paragraph, which assumes a full build.
> I think we need to make that clearer in the comments and that this is
> only useful on automated infrastructure.
I wouldn't say that. One could do "BUILDHISTORY_REMOVE_OLD=1 bitbake
<something> && bitbake <something else> && bitbake <even more>", and
that would work fine also when doing manual builds. The drawback in that
case is that the version-going-backwards check does not work for
<something else> and <even more>.
Perhaps it would be more appropriate to replace BUILDHISTORY_REMOVE_OLD
with "BUILDHISTORY_RESET"?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2016-02-08 12:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 6:56 [PATCH] buildhistory.bbclass: remove out-dated information on request Patrick Ohly
2016-02-08 8:52 ` Richard Purdie
2016-02-08 12:35 ` Patrick Ohly [this message]
2016-02-10 12:31 ` Paul Eggleton
2016-02-12 8:37 ` [PATCH v2] " Patrick Ohly
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=1454934920.8641.4.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@intel.com \
--cc=richard.purdie@linuxfoundation.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.