From: Patrick Ohly <patrick.ohly@intel.com>
To: Mike Crowe <mac@mcrowe.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner
Date: Wed, 08 Feb 2017 14:04:42 +0100 [thread overview]
Message-ID: <1486559082.13854.12.camel@intel.com> (raw)
In-Reply-To: <20170208115042.GA21576@mcrowe.com>
On Wed, 2017-02-08 at 11:50 +0000, Mike Crowe wrote:
> On Friday 13 January 2017 at 15:52:33 +0100, Patrick Ohly wrote:
> > Having do_rm_work depend on do_build had one major disadvantage:
> > do_build depends on the do_build of other recipes, to ensure that
> > runtime dependencies also get built. The effect is that when work on a
> > recipe is complete and it could get cleaned up, do_rm_work still
> > doesn't run because it waits for those other recipes, thus leading to
> > more temporary disk space usage than really needed.
> >
> > The right solution is to inject do_rm_work before do_build and after
> > all tasks of the recipe. Achieving that depends on the new bitbake
> > bb.event.RecipeTaskPreProcess and bb.build.preceedtask().
>
> We've run into trouble with this change. We have a number of custom
> ancillary tasks that are used to generate source release files and run
> package tests. No other tasks (including do_build) depend on these tasks
> since they are run explicitly when required using bitbake -c; either
> directly or via a recrdeptask.
>
> Running a single task continues to work correctly - presumably this is
> because the do_build task is not being run, so its dependencies (including
> rm_work) aren't run either.
>
> Running via the recrdeptask fails. This is because for any particular
> recipe we end up depending on both do_build and the source release tasks.
> There's nothing to stop do_rm_work running before (or even during!) one of
> the source release tasks.
Can you show how you use recrdeptask and how you call bitbake to trigger
those extra tasks, just for my understanding?
I suppose it worked before because your tasks could depend on do_build
without triggering do_rm_work, while now that is included.
> It seems that we need to ensure that do_rm_work also needs to depend on our
> ancillary tasks too, but only if they are being built. I'm unsure how this
> can be done though. :(
How do you determine whether the tasks need to run? Does it depend on
how bitbake is invoked or does it depend on specific properties of the
recipe?
--
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:[~2017-02-08 13:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 14:52 [PATCH v2 0/3] rm_work enhancements Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 1/3] gcc-source.inc: cleanly disable do_rm_work Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 2/3] rm_work_and_downloads.bbclass: more aggressively minimize disk usage Patrick Ohly
2017-01-13 14:52 ` [PATCH v2 3/3] rm_work.bbclass: clean up sooner Patrick Ohly
2017-02-08 11:50 ` Mike Crowe
2017-02-08 13:04 ` Patrick Ohly [this message]
2017-02-08 13:48 ` Mike Crowe
2017-02-09 16:24 ` Patrick Ohly
2017-02-10 18:32 ` Mike Crowe
2017-02-13 10:54 ` Patrick Ohly
2017-02-13 12:19 ` Mike Crowe
2017-02-13 12:43 ` Patrick Ohly
2017-02-17 15:21 ` Running task for all recipes required by an image (was Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner) Mike Crowe
2017-02-17 15:38 ` 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=1486559082.13854.12.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=mac@mcrowe.com \
--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 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.