From: Mike Crowe <mac@mcrowe.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 3/3] rm_work.bbclass: clean up sooner
Date: Wed, 8 Feb 2017 13:48:10 +0000 [thread overview]
Message-ID: <20170208134810.GA29105@mcrowe.com> (raw)
In-Reply-To: <1486559082.13854.12.camel@intel.com>
On Wednesday 08 February 2017 at 14:04:42 +0100, Patrick Ohly wrote:
> 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:
> > > 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?
Certainly, we have a bbclass globally in INHERIT that contains:
addtask source_release # potential fix here
do_source_release() {
:
}
addtask all_source_releases
xx_do_all_source_releases() {
:
}
do_all_source_releases[nostamp] = "1"
do_all_source_releases[recrdeptask] += "do_all_source_releases do_source_release"
addtask husk_recipe before do_source_release
python xx_do_husk_recipe() {
...
}
(there's also another task similar to do_husk_recipe)
and in the particular recipe that has trouble with racing against rm_work:
do_husk_recipe() {
# do stuff in ${WORKDIR}
}
addtask husk_recipe after do_populate_sysroot before do_source_release
there's also a source-release-world recipe that contains:
DEPENDS = "our-image"
and we run:
bitbake -c all_source_releases source-release-world
> I suppose it worked before because your tasks could depend on do_build
> without triggering do_rm_work, while now that is included.
I believe so.
> > 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?
Running bitbake as above.
I think that I could fix this by changing:
addtask source_release
to
addtask source_release before do_rm_work
(and also fixing any other tasks that suffer from this problem)
but I was hoping that there was a better fix to rm_work.bbclass itself.
Thanks.
Mike.
next prev parent reply other threads:[~2017-02-08 13:55 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
2017-02-08 13:48 ` Mike Crowe [this message]
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=20170208134810.GA29105@mcrowe.com \
--to=mac@mcrowe.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=patrick.ohly@intel.com \
/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.