All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.